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A három napos, gyakorlatokra épülő tanfolyamot SOL Server 2005 
(esetleg SOL Server 2000) adatbázis-adminisztrátorok, üzemelte- 
tők, fejlesztők részére ajánljuk, akik szeretnék ismereteiket frissí- 
teni SOL Server 2008-ra, és szeretnék elsajátítani az adatbázis 
üzemeltetési és fejlesztői újdonságait, az SOL 2008 eszközök és 
technológiák gyakorlati használatát. 





Előadó 






Árva Gábor (MCT), az SOL téma hazai szakértője, aki a márciusi, 
Redmondban tartott SOL Server 2008 konferencián is részt vett, így 
a legfrissebb információkkal, anyagokkal várja az érdeklődőket. 


Kedvezményes résztvétel! 







Korábbi SOL Server 2000 vagy SOL Server 2005 tanfolyamainkon 
résztvevők számára biztosítunk a májusi 
időpontra. A képzésre Microsoft SA oktatási bónok felhasználhatók. 


Csatlakozzon be most! 
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szereplő a vállalatok informatikájában. 


Microsoft a 90-es évek közepétől kezdve folyamatosan ostromolta a nagyvállalati infor- 

matika bástyáit és szervertermeit. A Windows NI megjelenésével egy olyan operációs 

rendszer alapjait tette le, amelyik egyesítette a Windows jól megszokott könnyű hasz- 
nálatát és széles körben használt programozói interfészeit a vállalati informatikában elvárt 
stabilitással, szálázhatósággal. 

Ezzel közel párhuzamosan a vállalati informatika egy másik nagy vonulatába, az adatbá- 
zisok piacára is belépett a Microsoft: megjelentette az első, teljesen Microsoftsszínekben ver- 
senyző SOL Servert (4.2, 1994-ben). Ez a kiszolgáló számos kiadást megélt már azóta, tudása 
egyre csak bővült és bővült, magába olvasztva egyre újabb technológiákat, új lehetőségeket 
adva a fejlesztők és üzemeltetők kezébe. A hagyományos relációs adatbázis fokozatosan ki- 
egészült egy erős OLAP-szerverrel, üzletiintelligencia-eszközökkel, beépített jelentéskészítéssel 
és magas rendelkezésre állást biztosító opciókkal - és mindezek azóta is a rendszer részét képe- 
zik: aki SOL Serverre bízza magát, az gyakorlatilag biztos lehet benne, hogy ezek a képességek 
nem drága opciók formájában, hanem alapszolgáltatásként járnak! 

Idén ősszel megjelenik a legújabb SOL Server, amely továbbfejleszti a nagyvállalati funkció- 
kört, amellett, hogy megtartja jól ismert skálázhatóságát is. Az ingyenes Express változattól 
a nagyvállalatok igényeit kielégítő Enterprise változatig számos újítást tartalmaz, amelyek a 
jelenkor adatbázis-kihívásaira válaszolnak. Új adattípusok, tömörítés, transzparens adattit 
kosítás, deklaratív adatbázis-menedzsment, erőforrás-priorizálás, új jelentéskészítő motor, 
Microsoft Office-ba integrált jelentéskészítés és számos más újítás erősíti a szoftvert. 

Az SOL Server 2008 próbaváltozata a Microsoft Connect honlapján - http://connect.micro- 
soft.com/sgl/ - már elérhető, érdemes kipróbálni. Ahhoz pedig, hogy segítsük a szoftver meg- 
ismerését, egy külön TechNet Magazin számot szenteltünk a legfontosabb újdonságoknak. 
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középvállalatok részére (file kiszolgáló , levelező rendszer) 
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Hogy mi a különbség? Az egyik könnyebb, mint a másik... 


áltoznak az idők. Az ipari forradalom idején a munkások szétverték a gépeket, azzal a 

felkiáltással, hogy azok elveszik a munkájukat. 2008-ban az informatikusok azért ütik- 

verik a gépeket, mert olyan kegyetlen sok munkát adnak. De a jelek szerint a Microsoft 
szereti az embereket, és az SOL Server 2008-ba jó pár olyan eszközt pakolt, amelyek az azo- 
nos teljesítmény eléréséhez szükséges emberi munkamennyiség csökkentését célozzák meg. 
Magyarán mondva: kevesebbet kell dolgozni. 

E cikk célja bemutatni azokat az eszközöket, amelyeket teljesítményhangolásra és monito- 
rozásra használhatunk az SOL Server 2008-ban. Nem esik tehát szó azokról az elemekről, 
amelyek egyszerűen csak javítják a teljesítményt minden különösebb felhajtás nélkül. Így nem 
írok a MERGE statementről, az adattömörítésről (mind a backup, mind az adatbázis szint 
jén), az adattárházak életét megkönnyítő Change Data Capture-ről és a tuningolt Integration 
Services lookupról, abba pedig véletlenül sem megyek bele, hogy a mirroring is hatékonyabb 
lett. Szigorúan csak arról lesz szó, hogy miféle módokon lehet a pillanatnyinál nagyobb teljesít 
ményt kicsalni az SOL 2008-ból, illetve arról, hogyan is tudjuk megmérni a pillanatnyi teljesít 
ményt. Tekintettel a bőség zavarára, mindkét csoportból egy-egy új eszközt választottam ki rész- 
letesebb boncolgatásra, a többiekről pedig majd egy későbbi alkalommal esik részletesen szó. 

Kezdjük a monitorozással, hiszen a teljesítményhangolás célja a szervert egy nem annyira jó 
állapotból egy jobb állapotba eljuttatni, és megfelelő monitorozó eszközök híján úgy járunk, 
mint a törpök, akik folyton azt kérdezték: , Törp Papa, messze vagyunk még?". Szóval ajánla- 
tos valamilyen monitorozást végezni a hangolás előtt és után is, hogy lássuk, javítottunk-e a 


helyzeten. 


Tudom, mennyi diszket használtál tavaly nyáron 

A teljesítménymonitorozás sok ember fejében összekapcsolódik a teljesítményproblémával, 
ám itt is igaz a régi mondás: ha békét akarsz, készülj a háborúra. Azaz aki nyugodt, békés üze- 
meltetői pályafutást szeretne, készüljön fel arra, hogy nem lesz benne része. Esetünkben ez a 
baselining nevű varázslattal, azaz a rendszer normál működés során történő monitorozásával 


valósítható meg. Képzeljük el, hogy egy tavaszi vasárnapon jelzik: nagyon lassú az egyik adat 
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bázis, megnézzük, és tényleg az, és kizárólag 
az ismert alkalmazás használja. Nekiállunk 
monitorozni, és azt látjuk, hogy a diszk ki 
van hajtva, és másodpercenként átlag 645 
téamzakció zajlik az adatbázisóanNagyszetű. 
Mi az összefüggés? Nehéz megmondani. Ha 
lenne egy baseline, amelyben látnánk, hogy 
mennyi volt békeidőben ugyanez a szám, ak- 
kor könnyebb dolgunk lenne, esetleg több- 
órás izzadás helyett rögtön kiszúrnánk, hogy 
megtízszereződött a forgalom valamiféle új 
üzleti tevékenység miatt. 

A teljesítménymonitorozás két régi pillé- 
re az SOL Profiler és a Performance Monitor 
az SOL Server teljesítményszámlálókkal. Az 
SOL Server 2005 pedig betömte a hiányzó 
lyukakat a Dynamic Management View-k 
(DMV) bevezetésével. Mit tudott még ehhez 
hozzátenni az SOL Server 2008? Még több 
DMV-t, még több performance countert, 
még jobb profilert, az Extended Eventset és a 
Performance Studiót. 

A Performance Studio igen érdekes elem. 
Mindenekelőtt jó tudni, hogy ilyen nevű 
gombócot nem nagyon fogunk találni az 
SOL Server menedzsmenteszközei között. Ez 
ugyanis leginkább egy keretrendszer, ami a 


már ismert Profiler és Performance Monitor 


Microsoft TechNet 
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1. ábra. A lemezfelhasználás vizsgálata 


mellett a Data Collection nevű új eszközt (ezt 
hívják még Performance Data Warehouse-nak 
is) foglalja magában, plusz egy APL-t a fejlesz- 
tők számára. De miért ilyen érdekes ez az esz- 
köz? Igazából semmi újat nem tudunk meg a 
segítségével az SOL Server működéséről, de 
ahogyan megtudjuk a már megszokott dol 
gokat, az merőben újszerű. A monitorozott 
adatokat ugyanis elraktározza egy adatbázis- 
ban, amiből rögtön lehet csinos riportokat 
generálni, illetve meg is őrzi ezeket tetszőle- 
gesen sokáig. Persze ilyet bárki tudott csinál 
ni eddig is, de legyünk őszinték: kinek volt 
kedve/ideje hozzá? És mindezt, mondjuk, 
19 szerveren? És nem utolsósorban: ilyen 
kicsi többletteljesítményigénnyel? Az SOL 
2008-ban egy pár kattintással beállíthatjuk a 
Management Data Warehouse (MDW) adat 
bázisunkat, ahogyan ezt itt nevezik. Három 
beépített szerepkör van hozzá: az író (aki be- 
tölti az adatokat) vaz olvasó (aki riportokat 
készít) és az adminisztrátor (aki művelt, írni 
és olvasni is tud), minden monitorhoz tarto- 
zik egy alapriport, és lehet szabadon készíteni 
további riportokat a Reporting Services se- 
gítségével, tehát szinte egy kész, riportolásra 
képes alkalmazást kapunk, semmi szükség 
arra, hogy furfangos kódok írásával töltsük a 
drága időnket. Nézzük meg, hogyan is műkö- 
dik ez a kis kütyü (I. ábra). 

A Data Collector egy egységes adatgyűj- 
tési megoldást használ különböző források- 
ból származó adatok betöltésére. Ez amellett, 
hogy végre kényelmesen összevethetővé teszi 
a különböző forrásból származó eseménye- 
ket, magában hordozza azt a nagyszerű le- 
hetőséget, hogy írhatunk hozzá saját bővít 


ményeket is. Az adatfolyamban a következő 


MÁRCIUS-ÁPRILIS 


új togalmakkal találkozhatunk, miközben, 

mondjuk, a sys.dm tran locks dinamikus 

nézetből a várakozó és a teljesített lock re- 
guestek számát töltjük be a miniradattárhá- 
zunkba: 

e Data Provider. Az adat forrása (esetünk 
ben az SOL Server instance, ahol a lekér 
dezés fog futni). 

e Collector Iype. Az ,egységesítő" réteg, 
ami az adatforras-specitikus információt 
MDW-kompatibilis állapotba hozza. Je- 
lenleg négy ilyen van: teljesítményszámlá- 
lókat, SCOL Trace-adatokat, LSOLlekér- 


dezéseket, illetve lekérdezésstatisztikákat 


EZT KV7 
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Teljesitett Lock Keresek, illetve Varakozo 
Lock Keresek neveket adhatjuk a mi kis 
adatgyűjtésünknek). 

e Collection Set. Egy vagy több Collection 
Itemet tartalmaz, amelyeket együttesen ke- 
zelhetünk (mi most két itemet tettünk 
bele a setbe). Ez az adatgyűjtési egység az 
adatgyűjtés során. 

Data Collector. Az MDW adatbázis mel 
lett as msdb adatbázist is igen intenzíven hasz- 
nálja, mivel egyrészt mind az adatgyűjtést, 
mind az adatbetöltést apró kicsi SSIS-csoma- 
gok végzik, másrészt a saját tábláit is itt tárolja 
(a syscollector kezdetűek tartoznak hozzá). 

Sokakban felvetődhet a kérdés: mennyibe 
kerül ez az eszköz, mennyi plusz-erőforrást 
igényel? Hiszen adatbázisa van, SSIS-csoma- 
gokat futtat, és elég sok adatot gyűjtöget 
össze. Körülbelül 5 százalék erőforrást tart 
sunk fenn neki, annyiból ki fog jönni (ez a 
szám napi 250350 megabájt adat gyűjtésé- 
re vonatkozik, ami egyáltalán nem kevés). 
Természetesen érdemes csak azokat az ada- 
tokat gyűjteni, amelyek szükségesek, hiszen 
minél többet gyűjtünk, annál több erőforrás 
kell. A teljesítmény kapcsán esetleg emlé- 
keinkből előszivároghat az ajánlás, miszerint 
például az SOL Irace-t diszkre kell menteni 
a legjobb teljesítmény érdekében, meg ha- 


sonlók. Szerencsére az SOL Server fejlesztői 
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2. ábra. A teljesítnényadatok gyűjtésének folyamata 


gyűjthetünk. (Mi a TSOL lekérdezést 
használjuk, hiszen egy lekérdezés a moni- 
torozásunk központi eleme.) 

e Collection Item. A Collector Iype egy 
konkrét (és nevesített) példánya (például a 


nemcsak írják, hanem olvassák is a saját aján- 
lásaikat, úgyhogy a begyűjtött adatok először 
egy könyvtárba kerülnek (ez a Data Collector 


Cache), majd onnan töltődnek be a MDW 
adatbázisba. Az igazán hatékony adatgyűj- 
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téshez a, MDW adatbázist másik szerveren 
érdemes tartani, mint amit monitorozunk 
(természetesen akár több szerverhez is hasz- 
nalhatjuk úgyanazt az adatbázist, 

Az apró kényelmetlenség a Data Collector 
használatában az lehet, hogy nincsen GUI a 
collection setek készítéséhez, csak I-SOL-ben 
tudjuk létrehozni őket (jó pár paramétert tu- 
dunk később állítani a GULn keresztül). A 
meglévő mintákat azonban ki tudjuk scrip- 
teltetni, és azokra (lés a Books Online-ra) tá- 
maszkodva egész könnyen legyárthatjuk sa- 
ját collection setjeinket. A riportok készíté- 
se pedig tényleg könnyű, néhány óra alatt 
elkészíthetünk olyan bonyolult riportokat, 
éves kimutatásokat, amelyekre nyugodtan rá- 
mondhatjuk a főnöknek: egész héten ezen 
dolgoztam (lén természetesen soha nem ten- 
nék ilyet, de a lehetőség adott). 

A másik új szereplő, az Extended Events 
vagy xEvents egy kicsit más súlycsoport. Ez 
egy eseménykezelő infrastruktúra, ami az 
SOL Server processz futása során bekövet 
kező események teljes körű monitorozására 
hivatott. A monitorozási lehetőségek sok he- 
lyütt átfedésben vannak az SOL Profilerrel, 
de annál jóval mélyebben nézhetünk bele az 
eseményekbe. 

A Profiler például mutatja a lock-esemé- 
nyeket, az xEvents pedig még a latch-ese- 
ményeket is mutatja, azaz amihez létezik 
esemény az SOL Serverben mint fejlesztett 
alkalmazásban, azt megnézhetjük vele. Az 
elkapott eseményeket az Extended Events 
Engine továbbítja az általunk meghatáro- 
zott eseménykezelőknek (targets), amelyek 
ennek hatására csinálnak valamit (action). 
Eseményfeldolgozó lehet például az Event 
TIracing for Windows (EI W) is, egy esemény- 
táj őevagy raz "Event iIbaitine, ami megadott 
szabályok alapján párosítja az eseményeket, 
és segítségével könnyen megtalálhatóak az 
egyedülálló események, például a lock, amit 
elfelejt elengedni egy processz. 

Az Extended Events egy roppant érdekes 
terület azoknak, akik már jártasabbak az 
SOL Server lelkivilágában, de meg kell fizet 
ni érte: ehhez az eszközhöz semmilyen gra- 
fikus segédlet nem létezik, kizárólag LSOL- 
ben (EWI-hez plusz parancssorban) lehet 
kezelni. Aki szeretne jobban megismerkedni 
vele (remélem, vannak ilyenek), az kezdetnek 
megnézheti a gyűjthető eseményeket az aláb- 


bi lekérdezéssel: 


select dxo.name, dxo.description, dxp.name 
from sys.dm  xe objects dxo 

join sys.dm. xe packages dxp 

on dxo.package. guid — dxp.guid 

where dxo.object type — "Event 


Mint említettem, az új eszközök mellett a 
régiekkel is foglalkoztak a fejlesztők. Az SOL 
Profilert nagyon nem kell bemutatni: az üze- 
meltetők és fejlesztők egyik legjobb barát 
ja, mivel könnyen, kényelmesen és gyorsan 
lehet vele megtudni, hogy pontosan mit is 
csinál a szerverünk, milyen utasítások vég- 
rehajtásával van elfoglalva, mindezt kényel 
mesen össze is kattogtathatjuk. Nos, most 
már van benne környezetérzékeny integráció: 
Management Studióból az eddig megszokott 
Tools - Profiler - kézi beállítás helyett egy 
SOMDArOMÁS TAN (könkattmntástajró myilikmáz 
SSMS mellé egy új Profiler-ablak, ami már be 
van konfigurálva, hogy az éppen aktív SPID- 
re szűrjön. Nem nagy dolog, de megint nye- 


rek vele egy kis időt. 


Túrjunk bele! 

A monitorozó eszközök után nézzük, mi 
ként lehet elérni, hogy a Performance Data 
Warehouse-unkból megnyugtató riportokat 
generáljunk. A triviális út az, hogy belejaví- 
tunk az adatokba, de próbáljuk meg a másik 
módszert: tuningoljuk az SÖOL-szervert egy 
kicsit. Már említettem, hogy elég sok telje- 
sítményjavító újdonság van az SOL Server 
2008-ban, ezek egy része azonnal rendelke- 
zésünkre áll, mindennemű módosítás nélk 
kül, egy részéhez pedig azért kell egy kicsit 
módosítanunk. Ezekre itt külön nem térek 
ki" kizárólag sa" klasszikus hangolásról "lesz 
szó. Induljunk ki egy képzeletbeli esetből: 
van egy alkalmazásunk, mögötte egy adat 
bázisunk SOL Server 2008-on, és egy bo- 
rús pénteki napon azzal talál meg minket a 
helpdesk, hogy az alkalmazás felhasználói 
bejelentések szerint botrányosan lassú, mi 
pedig megállapítjuk, hogy igazából az adat 
bázis a gyenge láncszem KLerre a feladatra a 
Profiler és a Perfmon tökéletesen alkalmas). 
Itt kezdődik az igazi stratégiai játék, ugyanis 
egyrészt meg kell találnunk a Perfmonnal, 
hogy milyen hardvererőforrásnak van szűké- 
ben a szerver, másrészt meg kell találnunk a 
Profilerrel, hogy miféle guery okozhat ilyen 
erőforráshiányt. 


Itt elérkeztünk az első valódi teljesítmény- 
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hangoló eszközhöz: bevethetjük a már jól is- 
mert automata fegyvert, a Database Engine 
Tuning Advisort (DETA), amelynek oda- 
adjuk a Profiler trace-t, és az majd kitalálja, 
hogy mit kell tenni az adatbázissal, hogy jobb 
legyen: indexeket, statisztikákat, particio- 
nálásokat ajánl, akár a meglévő mellé, akár 
ahelyett, ez csupán beállítás kérdése. Aki 
használta a DETA egyébként igen hasznos 
szolgáltatásait, az most kicsit kétkedve néz 
esetleg, hogy miért szeretném órákkal eltol 
ni a megoldást, mert a DETA amellett, hogy 
jó, lassú is, ami végül is érthető, csak nem 
mindig elfogadható. Egyszerűbb megoldás 
a Management Studióban nekiállni a végre- 
hajtási terveket bogarászni, ugyanakkor így 
adjuk meg magunknak az esélyt igazán nagy 
hibák elkövetésére, hiszen csak kiragadott 
részleteket próbálunk optimalizálni, esetleg 
a többiek rovására. Ez persze nem elrettentés 
akar lenni, csupán figyelmeztetés. 

Vannak azonban olyan teljesítményprob- 
lémák, amelyeket nem igazán lehet optimali- 
zálással megoldani. Például ha a lassulás oka 
az, hogy Robotka Robika riportokat készít a 
cég 15 éves történetéről napi és személy sze- 
rinti bontásban, akkor más eszközhöz kell 
nyúlnunk (nem Robika megfenyítésére gon- 
dolok). Ez a más eszköz pedig a Resource 
Governor, ami felszámolja az üzemeltető va- 
lós idejű erőforrás-zsonglőr tevékenységi kö- 
rét. A Resource Governor az, amit a neve 
sugall: hatalom az erőforrások felett. Jó, iga- 
zából pontosítani kell, az erőforrások köré- 
be egyelőre csak a processzor és a memória 
tartozik, ezeket lehet osztani, illetve elvenni, 
de az [/D-szabályozás is rajta van a fejlesztők 
listáján. 

Az alapséma könnyen átlátható a 3. ábra 
segítségével: definiálhatunk Resource Poolo- 
kat, amelyeknek kioszthatunk egy minimá- 
lis és egy maximális százalékértéket memó- 
riából és CPU-ból. Továbbá definiálhatunk 
Workload Groupokat, amelyekbe a procesz- 
szek kerülnek majd, és ezeket a workload gro- 
upokat hozzárendelhetjük a resource poolok- 
hoz, valamint adhatunk nekik prioritást is 
egy hármas skálán. Azt, hogy egy processz 
melyik workload groupba kerül, egy classifi- 
cation function fogja eldönteni. De nézzük 
meg mélyebben, hogyan is működik ez a 
konstrukció! 

A resource poolhoz rendelt minimum-erő- 


források azt határozzák meg, hogy mennyi 
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erőforrás lesz fenntartva mindenképpen az 
adott poolnak, a maximum pedig azt, hogy 
amennyiben az erőforrásért versengés folyik, 
legfeljebb mennyit kaphat a pool. Tehát egy 
adott resource pool lehetséges erőforrás-fel- 
használását meghatározza a többi pool mi- 


nimumértékének az összege. A minimumok 


a Management Studióban.) Az internal work- 
[dac eroupba soroljaraz SOL a sajat maga szá 
mára kritikus processzeket, és ezt az internal 
resource poolhoz rendeli. Ez nem szerkeszt 
hető, nem lehet ide sorolni user processze- 
ket, nem lehet korlátozni - és természetesen 
annyi erőforrást használ, amennyit akar, füg- 


getlenül a többi pool 
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beállításától. A defa- 
ult workload group a 
, gyűjtő , azok" a pro: 
cesszek kerülnek ide, 
amelyek nem illettek 
be máshova. A classi- 
fication function, ami 
a session létrejöttekor 
lefut, egy stringet ad 


vissza, és ezt a szerver 
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workload group név- 
ként értelmezi. Ha 
nincs olyan nevű work- 
load group, vagy el 


bukik a classification 
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3. ábra. Finomhangolható teljesítnénybeállítások 


Összege természetesen nem lehet 100 fölött, 
és amennyiben pont kijön a 100 százalék, 
gyakorlatilag előre le van osztva minden erő- 
forrás. Érdemes tehát jól meggondolni, hogy 
kinek és miért akarunk minimumértéket be- 
állítani, ez a minimum ugyanis kárba vész, 
ha nem használjuk. Ezek után senki sem fog 
meglepődni, ha a ResPooll néha 80 százalék 
processzoridőt használ el - ha van szabad 
kapacitás, akkor azért nem nehezíti az éle- 
tet az Erőforrás Kormányzó. Viszont 90 szá- 
zaléknál többet sosem használhat, mivel 10 
százalék mindig le van foglalva a ResPool2 
számára. A workload group olyan csoport, 
amibe megadott szabályok alapján kerülnek 
az SOL-xprocesszek. Ez a besorolás kapcsoló- 
dáskor történik meg, a processz szintjén, ké- 
sőbb semmilyen úton nem módosítható. 

Viszont a workload groupokat egyik 
resource poolból a másikba átmozgathat 
juk bármikor, illetve a workload groupok és 
resource poolok beállításait is tetszés szerint 
módosíthatjuk, amikor csak akarjuk. 

Az SOL Server 2008-ban két beépített re- 
source pool és két beépített workload group 
található: ezeket internalnak és defaultnak 
hívják. (A Data Collectionhöz kapcsolódó 


képen azt is láthatjuk, hogyan néz ki mindez 


MÁRCIUS-ÁPRILIS 


classification — functi- 

om akkor irány a! de 
fault, ami a hasonló nevű resource poolban 
dolgozik. A default resource pool paraméte- 
rei állíthatók ugyan, de érdemesebb létrehoz- 
ni egy saját poolt, szebb is, és nem kér enni, 
ha nem használjuk (hacsak nem adtunk meg 
minimumértékeket). Mindenképpen fontos 
tudni, hogy a classification function még a 
logon része, és ha nem fut le a timeouton be- 
lül, akkor a kliens a connection timeout élb 
ményében részesül. Ezért különösen fontos, 
hogy a classification function gyors legyen 
(még egy érv: a Resource Governor connec 
tion pooling esetén is minden sessionre meg- 
hívja a classification functiont). 

A processzor és memóriaelosztás mellett 
még van néhány hasznos paraméter, amit 
lehet állítani egy workload groupnál. A prio- 
ritást már említettem, ez akkor hasznos, ha 
egy resource poolban több workload group 
is van. Emellett megadhatjuk a párhuzamo- 
san futó kérések maximális számát, ha en- 
nél több érkezne, akkor azok várni fognak 
egy szintén meghatározható timeout ideig. 
Ha esetleg sikerült egy olyan konfigurációt 
összehozni, ami annyira rossz, hogy még a 
saját megváltoztatásában is megakadályoz, 
akkor sem kell kétségbe esni: a Dedicated 


Admin Console (DAC) az internal resource 


[midi x 


poolba tartozik, azon a kiskapun mindig 6e- 
juthatunk. 

Ez eddig jól hangzik, de hogyan tudom 
megnézni, hogy valójában mennyi memóriát 
eszik a resource poolom, illetve jól műkö- 
dilcera classílication tünection "amit ittam 
A válasz kézenfekvő: az új, illetve módosított 
menedzsmentnézetekben. Az új sys.dm re- 
source governor resource pools nézetben ta- 
láljuk a számokat, a sys.dm exec sessions és 
sys.dm exec reguests nézetek pedig gazdagod- 
tak egy group. id oszloppal. És el ne felejtsük: 
vannak új performance counterek is hozzá... 

Ha rendelkezésre állnak olyan lekérdezé- 
seink, amelyek néha jól futnak, aztán elrom- 
lanak, akkor a Plan Guide/Plan Forcing 
segítségével egy jó végrehajtási tervet meg- 
tapgadvaazt ihaszmalhatjuk, samis boldósan 
élünk. Fel kell hívnom azonban a figyelmet 
arra, hogy ha rossz tervet mentünk el, akkor 
szemrebbenés nélkül rontja a teljesítményt az 
SOL-szerver. Természetesen ezeket a terveket 
bármikor eldobhatjuk, ha már nem kellenek. 

Hab a tortán: FORCESEEK. Mindig nagy 
dilemma az optimizernek, hogy clustered 
index scant használjon vagy nonclustered 
index seeket, és aztán keresse meg a rekordo- 
kat drága bookmark lookup műveletekkel a 
WHERE feltétel feldolgozásakor. Eddig erre 
a covering index lehetett megoldás: felvet 
tük azokat az oszlopokat is az indexbe, ame- 
lyeket le akartunk kérdezni, illetve ennek 
szebb változata az included oszlopok SOL 
2005-ben. A FORCESEEK hint segítségével 
az optimizer dilemmáját szüntethetjük meg, 
hiszen arra utasítjuk, hogy a nonclustered in- 
dex segítségével dolgozzon. A Plan Guide és 
FORCESEEK használatához természetesen 
tartsuk szem előtt az alapelvet: csak akkor ve- 
gyük el az optimizer munkáját, ha biztosan 
tudjuk, hogy mit teszünk. 

Egy szó "mint száz: "az SOL Server 2008 
hangolhatósága igen sokoldalú: akár gyors- 
tapaszra, akár időtálló megoldásra, akár csak 
erőforrás-elosztásra van szükségünk, min- 
dent megtalálunk ebben az eszköztárban. 
És munkánk eredményességét minden hét 
fő reggel szebbnél szebb grafikonok is bizo- 
nyíthatják - ha beállítottuk a Performance 
Studjóban 

Bitemo Erik 

(erik.bitemo.hu) 

MCDBA, MCTS, senior adatbázis-adminisztrátor 
Walt Disney Magyarország 
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TÖMÖRÍTÉSI 
TECHNIKÁK 


A Microsoft SOL Server 2008 beépítetten 


támogatia a tömörítést. 


lsőképp azt érdemes átnézni, hogy milyen lehetőség volt a korábbi verziókban az adatok 

kisebb helyen való tárolására. Az első, a Microsoft által támogatott adattömörítési tech- 

nika az SOL Server 2005-ben jelent meg. Korábban az SOL Server 2000-ben a teljes adat 
bázist tömörített lemezre rakhattuk (írás és olvasás esetén is működött), de ez egy, a Microsoft 
által nem támogatott lehetőség volt. Ez a helyzetet változott meg az SOL Server 2005 megjele- 
nésével, amikor csak olvasható (read only) adatbázis, vagy fájlcsoport esetén lehetett tömörített 
lemezen tárolni az adatainkat. De ez bármennyire jó öletnek tűnt, nem volt érdemes használ 
ni, mert megjósolhatatlan sebességcsökkenéssel járhatott a lekérdezésekre nézve. 

Az SOL Server 2005 SP2-től kezdődően Enterprise és Developer verzió esetén a vardecimal 
adattárolási típust használhatjuk, amely a varchar, nvarchar, varbinary típusokhoz hasonló el 
ven működik. Fontos, hogy kliensoldalon ebből semmit sem látunk, továbbra is ugyanolyan 
formában kapjuk meg a lekérdezett adatunkat, így nem kell módosítanunk a már meglévő kó- 
dümköns 

Ennek az adattárolási típusnak a decimal, numeric adattípusokhoz képest az az előnye, hogy 
ha nem használjuk ki az adott mezőnél a maximálisan rendelkezésre álló helyet, akkor az SOL- 
motor kisebb helyen fogja tárolni az adatainkat. Ahhoz, hogy a vardecimal tárolási módot 
használhassuk az adott adatbázis (sp db vardecimal storage format), illetve tábla szintjén 
(sp. tableoption) is engedélyezni kell: 

USE master 
EXECsp db. vardecimal storage format AdventureWorks ON" 
USE AdventureWorks; 


EXEC sp. tableoption "Production. WorkOrderRouting", 
"vardecimal storage format , "ON; 


Azt, hogy érdemes használnunk ezt a tárolási formát, az exec sp estimated rowsize reduc 
tion for vardecimal táblaneve futtatásával tudhatjuk meg. Például az adventureworks adat 


bázison lefuttatva a következő kódot. 


exec sp. estimated  rowsize reduction for. vardecimal "Purchasing.PurchaseOrderDetail 


Azt láthatjuk hogy így az átlagos rekord- avg rowlen fixed, format avag. rowlen. vardecimal format ] row. count ) 
8788 


hossz 56 bájtról 51.94 bájtra csökkenne. Még 56.00 1 51.94 


egy nagyon fontos dolog van a változó hosszúságú adatok tárolásával kapcsolatban, mégpedig 








az, hogy ha nem fix hosszú az adat, akkor minden egyes rekordban tárolni kell azt is, hogy az 
adott rekord adott mezőjében milyen hosszú az aktuális adat. Ezt az úgynevezett , column offset 
array" tartalmazza, mégpedig úgy, hogy megmutatja, hol található meg az adott adattartalom. 
Ezt két bájton tárolja, így könnyen belátható, hogy például egy char(2) hosszú mezőt nem érde- 


mes varchar(2)-ként tárolni, mert az 1 karakter hosszú adat tárolásához is 3 bájt kell, szemben 


Ld 


E ze 


a char(2) 2 bájtjával. És ez így igaz a kisebb 
típusok esetében is, például az int (4 bájt), a 
smallint (2 bájt) és tinyint (1 bájt) tárolásához 
szükséges hely tovább már nem csökkenthe- 
tő ezzel a módszerrel. Így el is érkeztünk az 

SOL Server 2008 egyik új adattárolási for 

májához, az úgynevezett rekordtömörítéshez 

(row compression), amelyet az Enterprise és 

Developer verziók támogatnak. 

A rekordtömörítés megvalósításánál a kö- 
vetkező szempontokat vették a figyelembe a 
fejlesztők: 

a A numerikus adatokat (float, int, bigint, 
smallint) és azokat a típusokat, amelyek a 
numerikus adattárolási formán alapulnak 
(datetime, money) a vardecimal adattáro- 
lási módhoz hasonlóan lehessen tárolni. 

n Fix hosszú mezőket, például char(100) vál 
tozó hosszúságban tárolni úgy, hogy a fel- 
töltő karaktereket nem tárolják. 

a Az adatrekord leírásához szükséges hely 
csökkentése (mezők hossza, mezők kez- 
dete és vége az adott rekordban). Ezzel a 
technikával az SOL Server a maximum 
8 bájt helyet elfoglaló adattípusok - pél 
dául bigint (8), int (4), smallint (2), char(8), 


Adattípus Leírás 
i Ha az adat 1 bájton elfér, akkor csak 1 
smallint KANÉLS ÉN 
bájton tárolja az adatot 
s Csak annyi bájtot használ, amennyire 
szükség van 
Hét Csak annyi bájtot használ, amennyire 
§ szükség van 
decimal Vardecimal tárolási forma 
numeric Vardecimal tárolási forma 
bit 4 bit metaadat plusz 
smallmoney Intként tárolva (10 000-rel felszorozva) 
money Bigintként tárolva (10 000-rel felszorozva) 
A nullákat nem tárolja. A real típusnál a 
float, real mantissza nem tört részét tömöríti leg- 
inkább 
datetime Maximum 2 bájt megtakarítása 
: A tárolt értéktől függő tömörítés (2-3 bájt 
datetime2 6ú 99 ; 
megtakarítás) 
datetimeoffset . Maximum 2 bájt megtakarítás 
char A kitöltő karakter levágva 
nchar A kitöltő karakter levágva 
binary A kitöltő karakter levágva (0) 
timestam est 
: p Intként tárolva 
rowversion 
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datetime(8) - esetén csak 4 extra bitet 
használ fel (az eddigi 2 bájttal szemben) ar- 
ra, hogy változó hosszúságú adatként tárol 
ja az adott mező értékét. 

an A NULL, illetve O értékek ne foglaljanak 
el helyet. 

Arról, hogy a rekordtömörítés mely adat 
típusokra van hatással az előző oldali táblá- 
zat szól. A rekordtömörítésen felül az adat 
lapokat is tömöríthetjük (page compression), 
ami a következő algoritmus szerint műkö- 
dik: hajtsuk végre a rekordtömörítést, majd 
szűrjük ki az adott adatlapon belül egyező 
értékeket. (Kétlépéses algoritmus, az úgyne- 
vezett ,column-prefix", és , pagedictionary" 
lépésekből áll, ezeket később fejtem ki). Így 
ezekeket csak egyetlenegyszer tárolja el, attól 
függetlenül, hogy hányszor szerepel az adott 
adatlapon belül. 

Nézzük meg a gyakorlatban egy teoretikus 


példán keresztül, hogy ez mit is jelent: 


create database TestForCompress 

g0 

use lestForCompress 

create table Product( 

Product!D int identity(1, 1), 

Name varchar(80) not null default ", 

Status smallint not null default 0, 

ProductCategory int not null default 0, 

CONSTRAINT PK. ProductID PRIMARY KEY (ProductID) 


) 
60 


set nocount on 

Insert into Product (Name) values (SYSDATETIME()) 
go 10000 

select top 10." from Product 


Az eredményt a fenti ábra szemlélteti. 
Nézzük meg, hogy milyen helymegtakarí- 


tással járna a rekordtömörítés alkalmazása. 


exec sp. estimate data compression. savings "db", Pro- 
duct, NULL NULL "ROW 


A lenti táblázatot így kell értelmezni: tábla 
neve, séma neve, index azonosítója (0 — heap, 
1 - clustered index, LP - nonclustered index), 
partíció száma (1, ha nincs partícionálva), a 
jelenlegi beállításokkal lefoglalt hely, illetve a 
lekérdezett tömörítési beállításokkal mennyi 
helyet foglal majd el. (Figyelem, nem minden 
mezőt jelenítettem meg!) 

Ebből az következik, hogy a jelenlegi táb- 
la a rekordtömörítés után kb. 20 százalékkal 
kevesebb helyet foglal el. Nézzük meg azt is, 
hogy a lapok tömörítése után mekkora lesz a 


megtakarítás: 
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exec sp. estimate data compression  savings "dbo", Pro- 
duct, NULL NULL "PAGE" 


Így már jóval jelentősebb a megtakarítás, 
hiszen kevesebb, mint 1/3 helyen lehet el 


tárolni ugyanazokat az adatokat. De ismer- 





A Results ) Ea Messages] 

ProductID : Name 

(d FT! 2008-03-07 10:12:36.7625024 
(7 BA OOGC3G7 IR T2 ZS ZEZSÜZS 
E 2008-03-07 10:12:36.7625024 
: 2008-03-07 10:12:36.7625024 
2008-03-07 10:12:36.7725168 
2008-03-07 10:12:36.7725168 
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jük be, ez nem életszerű, mivel a nevek ilyen 
nagymértékben nem hasonlítanak egymás- 
hoz. (Az adatlap-tömörítés az egyező értéke- 
ket csak egyszer tárolja, így a Name mezőben 
a ,2008-03-07 10:12:36." részt és a 0 értéke- 
ketió) 

Hogy ne legyen ilyen sok egyezőség, futtas- 
suk le az alábbi scriptet: 


update product 
set name— case when productid/2"2— productid then 
cast(productid as varchar(80)) else  cast(newid() as 
varchar(80)) end, 
status — cast(productid/273 as smallint), 
ProductCategory — cast(ProductID/7" - 
RAND(100)"100 as int) 


select top 10." from product 





Eredmény: 
ProductID . Name Status . ProductCategory 
1 Í1 ——— ! OG34DEFA.1363-488C-ADF5-AFBCGABB25CF 0 0 
sz 2 3 10 
ga 3 7B2B7CD2-F69E-4D5C-9DAF-B3FZCA5B91E4. 3 0 
a 4 6 0 
5 5 815FA340-88E 3-448F-808E-FABDOFDFF319. 6 0 
3 E 6 9 0 
7 E 15774E4E-69D8-444D-BA60-60544B27D28B 9 71 
8 8 8 12. 171 
9 9 26BF9194-3FO9-4AFF-A345-EO125BICA473 12 71 
10 10 10 15 71 














Tekintsük meg, hogy mennyi lenne a 


megtakarítás, ha tömörítenénk az adatla- 


(mlEdil x 


exec sp. estimate data compression  savings "dbo", Pro- 
duct, NULL NULL PAGE" 


A becsült helymegtakarítás 20 és 40 száza- 
lék közötti lehet az adattartalomtól függően. 


Nézzük meg a valóságban is: 
exec sp. spaceused "product 


Kapcsoljuk be az adatlap-tömörítést. (Ez a 


rekordtömörítést is használja.) 


ALTER TABLE product 

REBUILD WITH (DATA. COMPRESSION — PAGE) ; 
G0 

exec sp. spaceused "product 


A tömörítést nemcsak a táblára, hanem 
adott fájlcsoportra, indexre is be lehet kap- 
csolni, de ne felejtsük el, hogy a tömörítés 
használatakor további erőforrásokra (procesz- 
szor) lesz szükség, és a tömörítés eredményes- 
sége mindig az adott adattartalomtól függ, 
így nem minden esetben éri meg a használa- 
ta. Két eset, amikor szinte biztos, hogy érde- 
mes használni a Page compressiont: 

a Olyan fájlcsoportoknál, amelyek nem, 
vagy nem gyakran változnak (például read 
only). 

a Azoknál az indexeknél, amelyeket csak rit 
kán használja a rendszer. 

Azok az esetek, amikor nem érdemes hasz- 
nálni a tömörítést: 

a Amikor az eredeti tábla méretéhez képest 
túl kicsi a megtakarítás. 

a Nagyon sok írás/olvasás történik az adott 
objektumra. 

a Az objektum mérete az adott adatbázis 
méretéhez képest kicsi. 

Azt, hogy mely objektumokat használják 
viszonylag keveset a lekérdezések az adott 
adatbázisban, az sys.dm db index . opera- 
tional stats DMV (Dynamic Management 
View) lekérdezésével tudhatjuk meg. 

Nézzük meg, hogyan működik a , column 


prefix compression". Az SOL Server, a ,col 





assssssasesrszzzzzszsssssssssséés00 


pokat: umn compression" használatakor oszlopon- 
J object name . schema name . index id partition number size with current compression setting... — size with reguested compression settingíKkB] 
1 (Product — ! dbo 1 1 520 416 








Helymegtakarítás a tömörítés használatával 





object name  schema name " index id partition num... 


1 Product — !dbo j 1 520 


size with current compression setting... 


size with reguested compression settinolkB] 
160 





Helymegtakarítás a lapok tömörítése után 





size with current compression setti... — size with reguested compression setti... 
: 520 ! 416 448 





sample size with current compression settingíkB] sample size with reguested compression setting(KB]) 


360 








Helymegtakarítás az adatlapok tömörítése után 
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kénti mintát keres, mégpedig úgy, hogy olyan 
értékek után kutat az adott adatlapon, ame- 
lyek minden rekordban előfordulnak. Ahogy 
az elnevezésből is következik, csak kezdeti 
egyenlőségeket keres - például a következő 
két hexadecimális értékben csak a OxIIAA 
részt tekinti egyenlőnek: OxXIILAABBCCD- 
DAA, OxIIAACCCCDDAA. A ,DDAA" 
részt pedig nem tekinti egyezőnek. 

Hogy miért van ez így? Mintákat keresni 
az adatlapokon költséges művelet (főleg a pro- 
cesszort terheli), ezért a fejlesztők úgy döntöt 
tek, hogy csak a kezdeti egyenlőségeket dol 
gozzák fel, a többit , veszni hagyják". Ebből kö- 
vetkezik, hogy a OXAABBCC és Ox1IBBCC 
értékekre nem tud tömöríteni az SOL Server. 

Mielőtt tovább mennénk, fontos leszögez- 
ni, hogy bájtmintát keres az SOL Server, 
így típustól függetlenül minden adattípusra 
ugyanúgy működik a tömörítés. 

Nézzünk egy gyakorlati példát. Képzeljük 
el a következő táblázat szerinti adatstruktú- 
rát, amelynek egy adatlapját jelenítjük meg, 
az áttekinthetőség miatt szavakat használok, 


nem pedig hexadecimális számokat: 
Fejléc-információ (header) 


1 adatlap (8K) ID Terméknév Státusz 


1. rekord A01 Asztal X01 
2. rekord A02 Asztalra vissza. X03 
3. rekord A03 Asztalos X02 


Tömörített adathoz létrejön egy úgyneve- 
zett ,anchor" rekord, amelynek szerkezete 


ugyanaz, mint a többi rekordnak: 


Fejléc-információ (header) 


ekor ADB ásza NO 
1 adatlap (8K) ID Terméknév Státusz 
1. rekord A01 Asztal X01 
2. rekord A02 Asztalra vissza. X03 
3. rekord A03 Asztalos X02 


Az , ID" mezőből a rekordok közül az A03 
értéket választotta ki az algoritmus, így az 
1. rekordban a 21 azt jelenti, hogy az ,an- 
chor  mintabol"az első 2. bájtot hasznalja, 
és ezután a maradványértéket hozzárakja. A 
2. rekordban a szintén csak az első két báj- 
tot használja, majd a maradványérték kerül 
hozzá, így lesz az értéke 22. A 3. rekordnál 
pedig a teljes minta használható, így , null" 
értéket tárol az SOL Server. A többi mező ér 
tékeit ugyanígy feldolgozva jön létre az aláb- 
bi táblázat: 


1 


Fejléc-információ (header) 


ekor ADB ln 

1 adatlap (8K) ID Termék név Státusz 
1. rekord 21 6 vil 

2. rekord 22 Null 23 

3. rekord Null 605 Null 


Mindezeket követően, ha az adatlap-tömö- 
rítés is be van kapcsolva, akkor a következő 
táblázathoz hasonlóan nézhet ki az eddig be- 
mutatott adatlap: 


Fejléc-információ (header) 


ekor ADB vm A 
Adatlapszótár: 21 

1 adatlap (8K) ID Terméknév Státusz 
1. rekord 0 6 0 

2. rekord 22 Null 28 

3. rekord null 605 Null 


A táblázatot a következőképpen kell értel 
mezni. Az SOL Server megkeresi azokat az ér- 
tékeket az adott adatlapon, amelyek megegyez- 
nek, és szótárként használja őket. Pirossal 
jelöltem meg a táblázatban a változásokat. 
Mivel a 21 érték két mezőben szerepelt, ezért 
az SOL kiválasztotta szótár értéknek, majd 
ezeket , 0" értékkel helyettesítette be. Így nem 
magát az értéket tárolja, hanem csak azt, hogy 


a szótárban hányadik elemet foglalja el. 


Backup tömörítési technika 

A mentéseket tömöríteni a korábbi SOL 
Serververziókban csak más gyártók termé- 
keinek megvásárlásaival lehetett. Sajnos csak 
Enterprise és Developer verzió esetén hasz- 
nálhatjuk a tömörítést, azt pedig, hogy mi le- 
gyen az alapértelmezett mentési forma, szer- 
ver és adatbázisszinten adhatjuk meg. Az 
így beállított érték akkor jut érvényre, ha a 
BACKUP parancs futtatásakor nem adjuk 
meg, hogy tömörítse vagy ne tömörítse az 
adatokat. 


USE master; 

G0 

EXEC sp. configure "backup compression default, "1 ; 
RECONFIGURE WITH OVERRIDE; 


A mentésnél a WITH záradék egészült 
ki a COMPRESSION opcióval. Lefuttatva 
az alább scriptet a virtuális gépemen 15 
másodperc alatt futott le a BACKUP a 
COMPRESSION opcióval, és 39 másodperc 


e ze 


alatt a tömörítés nélküli. A fájlméret 394, il 
letve 172 megabájt. Látható, hogy a tömörítés 
gyorsabb volt, és kevesebb helyet foglalt el. 


declare COdatetime datetime — GETDATE() 
BACKUP DATABASE Adventureworks 

10 DISK — "CNYadventureworks.bck" 

WITH INIT COMPRESSION 

select getdate()-(Odatetime 


set Odatetime — GETDATE() 
BACKUP DATABASE Adventureworks 
10 DISK — "CYyadventureworks1 .bck" 
WITH INIT 

select getdate()-(Odatetime 


Mint mindennek, a tömörítésnek is ára 
van: Az alábbi ábrán látható, hogy a tömött 
tett mentés jóval nagyobb processzorterhelt 
séggel jár. 

A tömörített mentéseket bármelyik SOL 
Server-verzió vissza tudja állítani, azt, hogy 


az adott backup fájl tömörített formátumú 








3. ábra. Processzorterheltség 





BackupName  BackupDescription  BackupType ExpirationDate . Compressed 


1 NULL NULL 1 NULL :1 i 


kereseszszzseteseretessesesetésésesi 








vagy sem, a RESTORE HEADERONLY pa- 
ranccsal nézhetjük meg, ahol a Compressed 
mező 1 értéke jelenti azt, hogy a mentés tö- 


mörítve van. 


Konklúzió 
Bár a háttértároló rendszerek kapacitása egy- 
re nő, és az árak is csökkennek, de az adatok 
tömörítésével a rendelkezésre álló hely to- 
vább növelhető, és nem elhanyagolható té- 
nyezőként a kiírásra, olvasásra, mentésre és 
visszaállításra fordított idő a Microsoft SCOOL 
Server 2008-ban megjelent megoldásokkal 
jelentősen csökken. 
Sáfár István 
(isafarr Dcleware.hu), Architect 


Microsoft TechNet 
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Hogyan és mivel lehet megfegyelmezni az SOL Server 2008-at. 


z SOL-szerver új verziója jelentősen átalakítja a menedzsmentfeladatok elvégzését. 

Eddigi eszközeinkkel - jobok, triggerek, profiler - korábbi SOL-verziókban követhet 

tük a szerveren zajló változásokat és reagálhattunk rájuk. Jobokkal automatizálhat 
tunk folyamatokat, sőt ellenőrizhettünk szerver: és adatbázis-opciókat, ha azok nem voltak 
megfelelőek, akkor változtathattunk rajtuk. Ellenőrizhettük, hogy az előre eltervezett beállítá- 
soknak megfelelően működik-e szerverünk, ha nem, esetleg egy DDL triggerben visszagördít 
hettük, egy jobban beállíthattuk, ha nem így történt. Ha egyszerre több szerveren akartunk 
valami hasonlót, akkor már bonyolult volt ezt megvalósítani, frissíteni. 

Kialakíthattunk mindenféle névkonvenciót a táblák, triggerek, objektumok nevére, szer- 
ver, illetve adatbázis-opciókra vonatkozóan. (Például minden tárolt eljárás neve proc " alakú 
legyen, éles adatbázis recovery-modellje legyen FULL, mindig be legyen állítva az indexstatisz- 
tika készítése és frissítése, és még sorolhatnánk. Ahhoz, hogy ezeket az igényeinket kielégíthes- 
sük, saját magunknak kellett fejleszteni triggereket, jobokat stb. 

Összefoglalva a jelenlegi verziókban a következő eszközöket használhatjuk erre a célra. 

SOL Server Agent. [Időzített jobokkal aszinkron módon riasztásokat válthatunk ki vagy rea- 
gálhatunk rájuk. 

DDL triggerek/ Event notification. Szinkron és aszinkron eseménykezelés az SOL Server 
2005-től kezdődően. 

SOL Server Best Practices Analyser. Külön letölthető ellenőrző eszköz több művelet, beál 
lítás ellenőrzésére SOL 2000, 2005-ös verzióban. 

SOL Server 2005 Surface Area Configuration Tool. Az SOL Serverpéldány egyes szolgál 
tatásainak beállítása/ellenőrzése. 

Az SOL Server 2008-as verzióban a fent vázolt feladatok elvégzését segíti az az eszközrend- 
szer, amelyet Declarative Management Frameworknek (DMF) hívunk. Mit takar ez a fogalom, 
hogyan használjuk, és miért is jó ez nekünk? Erre szeretnénk rávilágítani ebben a cikkben né- 
hány példával fűszerezve. A fentebb felsorolt eszközök (job, trigger, profiler, database mainte- 
nance plan) természetesen továbbra is rendelkezésre állnak, a DMF kiegészíti, teljessé teszi a 


velük elvégezhető feladatokat, rendszert visz az adminisztrátori feladatokba. 


Mi a DMF? 


A Declarative Management Frameworkről a 2007. júliusi CTP-ben még Dynamic Management 
Framework fedőnéven lehetett olvasni, azóta ez persze a helyére került. Tulajdonképpen Policy 


Based Frameworknek is nevezhetnénk. Ugyanis az eddigi feladat (task) alapú adminisztrációt 


MÁRCIUS-ÁPRILIS 


a házirend (Policy) alapú adminisztrációra 
cseréli. 

Dióhéjban Ssazcadmimniszttator aza SOT 
Server Management Studióban (SSMS) lét 
rehoz házirendeket, amelyek leírják, milyen 
feltételeknek, kondícióknak kell teljesülniük 
az adatbázisban (például minden tábla neve 
a (tbl karaktersorozattal kezdődik, mindig 
be van kapcsolva az indexstatisztikafrissítés 
stb). Ezután hozzárendeljük, mely szerverek: 
re, adatbázisokra jusson érvényre a házirend, 
amelyet egy központi konzolról ellenőrizhe- 
tünk. Ezek a házirendek az MSDB adatbá- 
zisban tárolódnak, exportálhatók, importál 
hatók. Nagy hasznát vehetjük nemcsak több 
szerveres üzemeltetés esetén, hanem teszt 
szerver kialakításakor is. Tehát házirendeket 
definiálunk feladatok (task) helyett. 

Ezzel a házirend fogalma utat tört ma- 
gának az SOL Serverben is. Eddig csak az 
Active Directory, Ras-szerver környékén tüs- 
ténkedők találkozhattak vele. Most már az 
adatbázis-adminisztrátorok sem kerülhetik 
el. Persze fontos megjegyezni, hogy a DMF 
házirendjei nem keverendők össze az előbb 
említettekkel. Az SOL Serverben a házirend 
az MSDB adatbázisban található: 

Az előjáték után nézzük meg a szereplőket, 
tehát az eposzi enumeráció következik: 

Három komponens alkotja a keretrend- 
szert: 

Házirend-menedzsment. Házirend létre- 


hozása az SSMS segítségével. 


Le 
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Explicit adminisztráció. Kiválasztjuk a 
házirend célját, a szenvedő alanyt, vagyis a 
, pácienst". 

Automatikus adminisztráció. Mikor érté- 
kelődjön ki az a házirend? 

És még egy kis terminológia, lássuk a 
DME-hez tartozó objektumokat: 

Facet. Logikai jellemzők csoportja egy 
adott objektumtípusra (például: tábla, adat 
bázis stb.), beépített. Házirendek, kondíciók 
létrehozásánál használjuk. 

Kondíciók (Condition). Logikai feltéte- 
lek, amelyeket mi hozunk létre. A megkívánt 
(elérendő) állapotot írjuk le vele. 

Házirend (Policy). Kondíciókat tartalmaz, 
és egy adott objektumra, szerverre, adatbá- 
zisra vonatkozik, meghatározza a végrehajtás 
módját. 

Házirendcsoport (Policy Group). Házi 
rendek csoportja. Egy házirend egy csoport 


nak lehet tagja. Könnyíti az adminisztrációt. 


Feltételek 


Cél objektum 













Kitaláltuk, hogy egy adatbázisban minden 
felhasználói táblának a tbl" karaktersorozat 
tal kell kezdődnie, és tetszőlegesen folyta- 
tódhat. Ha valaki nem 


I [1——] 
NN 


o 


juk a Name tulajdonságot. Ebben a nézet 


ben csak szemlélődünk, mint a moziban. 


Ha be akarunk szállni a buliba, akkor a 





ilyen kezdő karakterso- 
rozattal hoz létre táblát, 
azt akadályozza is meg 
az SOL Server. Ezt kel 
lene megvalósítani a 


DMEF eszközeivel. DMF 





5 T STÁRGÁATELSOL2008 (SOL Server 10.0.1300 - STARGATElarvag 
[A Databases 
CA Security 
CA Server Objects 
CA Replication 
EH CA Management 
CÉNTÉPolicy Management 





nélkül kellene írnunk A) CA Policies 
egy DDL triggert, amely Ld Conditions 
a create table eventre ki [d Facets 








gerjed, és ha az első há- 
rom bötű nem tb! vala, 
akkor tollback transaction 
Ez is megfelelő megoldás lenne, de minden 
esetben egy rövid kis kódot kellene írni hoz- 
zá. Hogyan lehet ezt , trendi" módon az SOL 
Server 2008 DMEF segítségével kivitelezni? 
Ehhez használjuk az SSMS-t mint eszközt. 





Házirend 

Cél állapot 
Mit-mikor 
ellenőriz 
kategória 


AGYÁT LekÁ Troj 
MELYAT Ph [d) 








1. ábra. A DMF architektúrája 


Végrehajtási mód (Execution mode). 
Hogyan hajtódjon végre a házirend, azaz mi- 
kor, mi módon? A cikk későbbi részében rész- 
letesen kitérünk ezekre a lehetőségekre. Most 
kedvcsinálónak felsoroljuk a lehetőségeket: 
an manuálisan futtatható; 
m beállított időzítésnek megfelelően; 
nm csak logolja, mi történt a házirenddel kap- 
csolatban; 
a végül, ha ellentétes a házirenddel, akkor 
akadályozza meg a változtatást. 
Azoknak, akik képregényen nőttek fel, kö- 


vetkezik egy ábra (1. ábra). 
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Ha a Management konténert kiböngésszük, 
akkor feltűnnek az új objektumok (2. ábra). 

A facets konténer tartalmazza objektum- 
típusonként a faceteket, amelyek az adott 
objektumtípus (tábla, schema stb...) ellenőriz- 
hető, beállítható jellemzőit tartalmazza, csak 
ezekre vonatkozóan adhatunk meg feltétele- 
ket (Condition). 

A Kondíciók konkrét logikai kifejezések, 
amelyek a facetekben található jellemzőkre 
vonatkoznak. Kötelező elemei a kondíció- 
nak, ezáltal a házirendnek. 


Például a Table facet jellemzői között lát 


2. ábra. Új objektumok a Management konténerben 


Kondíciók (Condition) konténerben egy ha- 
tározott jobb klikk és új Kondíciókat választ 
va (4. ábra) adhatunk nevet a kondíciónak. 
Kiválaszthatjuk a tábla objektumfeltételkész- 
letéből (table facet), hogy a név Oname tulaj- 
donságra akarunk feltételt adni, nevezetesen 
Adname — tbl96, ezzel kész a feltétel. Már hasz- 
náltunk is két objektumot a DMF-ből. De ez 
a Kondíció még , csak lóg a levegőben", kötni 


kellene még valahova. 


Declare (condition. id int 
EXEC msdb.dbo.sp. syspolicy add condition name 
—NTábla név, 
(description N", (Ofacet—N Table, 
(expression—N cOperator— 
ypeClassz Bool-C/TypeClassz 
cOplypeszlIKEG/Oplypez 
(Count 2c/(ount— 
a httribute— 
ypeClassz String €/TypeClassz 
cNamesz Name €/Namez 
c/Atributex 
cConstant— 
ypeClassz String €/TypeClassz 
cObjlypezSystem. String C/Objlypez 
Valve tbl99 c/Valve 
c/Constant— 
c/Operator— ", (Mis name condition—2, (Dobj. name 
—Ntbl99, 
(Ocondition. id — (condition. id OUTPUT 


De előtte nézzük meg, hogyan néz ki ez a 
Kondíció , tudományosan" LSOL ben, mert 
amit összekergetünk az egérrel, azt le is scrip- 
telhetjük, és akkor bemutatókon el tudjuk 
ámítani a népet, hogy micsoda hard core fic- 
kók vagyunk (3. ábra). 

Hateevan asKkondíció, "akkor "ahogy 
korábban említettük - alkalmazni kellene. 
A feltétel, ugye, táblára vonatkozik, de nem 
mondtuk meg, melyik táblára, mikor érté- 
kelődjön ki, mi lesz, ha nem teljesül, és így 


tovább. Ehhez kell a házirend, ebben adjuk 


Microsoft TechNet 
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meg, melyik kondíció milyen objektummal 
kerüljön kapcsolatba és hogyan, a hogyan 


lesz a végrehajtási mód (execution mode). 


hozva létre egy bonyolultabb kifejezést mint 
Kondíciót. Itt kell meghatározni a végrehaj- 


tási módot. 





d Script" Új Help 


67 Dependent Policies 


(AA Dependent Conditions Description: 


Properties: 
AnsiNullsstatus 
ChangeTrackingEnabled 
CreateDate 
DataSpaceUsed 
DateLastModified 
FakeSystemTable 
FileGroup 
FileStreamFileGroup 
FilestreamPartitionscheme 
HasáfterTrigger 
HascClusteredindex 
HasCompressedPartitions 
HasDeleteTrigger 
Haslndex 
HaslnsertTrigger 
HaslnsteadofTrigger 
HasUpdateTrigger 
ID 
IndexSpacelsed 
IsIndexable 
IsPartitioned 


Connection 


Server: 
STARGATELSOL2008 


Connection: 
STARGATElarvag 


IsSystemObject 

IsvarDecimalStorageFormatEnabled 

LockEscalation 

a View connection properties 
Partittionscheme 


Progress 





3. ábra. A kondíciónk beállításai grafikusan 


A házirend létrehozásánál meg kell ad- 
nunk egy nevet a házirendnek, engedélyez- 
nünk kell, és ami a legfontosabb, meg kell 
mondanunk, hogy melyik kondíció tartozik 


hozzá. Egyszerre csak egy kondíció tartozhat 


E. Facet Properties - Table 


zIDIX1 


Exposes properties of the Table object. 
öpplicable target types: ] Table Teszt] 


Gets the Boolean property value that specifies whether SOL a 
Specifies whether change tracking is enabled. 

Gets the date and time when the table was created. 

Gets the storage space used by the rows of the referenced 
Gets the date and time when the table was last modified. 

Gets the B00lean value that specifies whether the table is re 
Gets or sets the filegroup where the table is stored. 

Gets or sets the filestream filegroup where the table is store 
Gets or sets the filestream partition scheme configured for t 
Gets the Boolean property value that specifies whether the 
Gets the Boolean property value that specifies whether the 
Gets the Boolean property value that specifies whether the 
Gets the Boolean property value that specifies whether the 
Gets the Boolean property 


Gets the Boolean property value that specifies whether the 


a 
a 
value that specifies whether the 
a 
a 


Gets the Boolean property value that specifies whether the 
Gets the ID value that uniguely identifies the table, 

Gets the space used by the index, in kilobytes. 

Gets the Boolean property value that specifies whether an it 
Gets the Boolean property value that specifies whether the 





Gets the Boolean property value that specifies whether the 


Gets or sets a Boolean property value that specifies lock esc 


Gets or sets the name of the object (inherited from NamedS 


Gets or sets the partition scheme configured for the table. — 


Gets or sets the name of the object (inherited from NamedSmoObject) 





a On demand. Manuálisan futtatható az 
Evaluate opcióval (ez egyébként minden 


más opció választásakor is lehetséges). 


ez [d pu 
VV kann ms 


mény történik, nem akadályozza meg, csak 
logolja az eseményt. 
a On 


Kondíciókban leírtakkal ellentétes ese- 


Change -  Prevent. Amikor a 
mény történik, nem engedi a változtatást, 
megakadályozza azt. 

Ezenkívül szűrhetünk a szervertulajdon- 
ságra vonatkozóan is, a Server restriction me- 
zőben megadhatunk egy kondíciót, ami kor 
látozhatja a futtatószerverek körét. 

A description lapon opcionálisan meg- 
adhatunk egy kategóriát, (ha nincs, csinál 
hatunk egyet) ez segít kategorizálni a házi 
rendeket, ha a házirendjeink száma lelkese- 
désünkből fakadóan a végtelenhez tart. A 
Description mezőben dokumentálhatunk, 
nem úgy, ahogyan az ábrán látszik. Ezenkívül 
megadhatunk egy üzenetet, ami a logban 
majd segít a tájékozódásban egy url kísére- 
tében, amit persze tesztelhetünk is. (Erre az 
urlre kattinthat majd az a rendszergazda, aki 
szeretne bővebb infóhoz jutni, ez lehet egy ol 
dal az intraneten, ami, mondjuk, a követen- 


dő adminisztrációs technikákat taglalja.) 


Műveletek házirendekkel 


Ha a házirend végrehajtási módját on de- 
mand-ra állítottuk, akkor humán interface 
segítségével  elindíthatjuk a kiértékelést 
(Evaluate), azaz rákattintunk. A fenti példa 
esetében valami hasonlót kapunk, mint ami 
a 7. ábrán látható. 


A komoly példaadatbázisban három egész 









MESS 5— Id 
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STARGATELSOL2008 (SOL Server 10.0.1300 - STARC( 







































































































































































A) Ü Databases e 
VzEÁN .. , A) Ca Securi Facet: Ífbe e 5 A] CA össem 
egy házirendhez. Ha többet szeretnénk, ak- Eulöő semen EBSESSELEBB 4 li At. 
A] CA Replication Connection Expression: TF Backuj 
10 16 171 Í - Ca Management erver: ndor ! Fiel erator ) Value ek Certifi 
kor jon jól a Házirendcsoport (Policy group). - feles Management STARENTÉSOLZÓGB , 509 TAK RE : hieke 7) Ca Chang 
. . z a Follcles Connection: Ede tsza ta sálja és s Datab. 
Meg kell adnunk, mely objektumokra jusson - a ETET egTtgaT TT "TARGaretervag leér kó sétálás 2 Mis 




















a view connection properties 











Filter tt erzi la 








érvényre (jelen esetben minden táblára), és 

































. 3 betete Reports Advanced edit enables free-form editing of available fungafons to use as cell values in the condition expression 
. . al 2 Resource 
azt is meg kell mondanunk, melyik adat 71 CA Malntenal Refresh Ready celtális 
Fi SOL Server Logs 








ég Activity Monitor 

3 Database Mail 

ő Distributed Transaction Coordinator 
Fi Legacy 

EB SOL Server Agent 


bázisban (5. ábra). Persze az ábrán látható a 

















csalafintaság, mert valójában több Kondíciót 











használtunk fel, hiszen a célkobjektumkör 


meghatározásához felhasználtunk egy szűrő- 





feltételt az adatbázisra vonatkozóan, ami ter- 


Functions and properties: Details: 


ÉT aLockEscalation A] ( Gets or sets the name of the object. (inherited from A 
ce NamedSmoObject) 

a 2 ösi 
(aPartitionscheme 

ZA mOnatedíidentifierstatuz s! d 


OK l Cancel ! Help l 
Le 






mészetesen újabb kondícióként jelenik meg. 


Tehát tovább pontosítva: egy kondícióban 





adhatjuk meg, mit kell ellenőrizni, betartat 


ni, azt pedig, hogy hol, több kondícióban is ! 4. ábra. A kondíciónk beállításai a mélyben 


leírhatjuk. Persze az egy kondíció nem olyan 


szigorú feltétel, mert mint ahogy azt a ko- 1! " On Schedule. I[dőzítésnek megfelelően az ! darab táblánk van - így legalább áttekinthet 


rábbi párbeszédpanelen láthatjuk (4. ábra), SOL Agent Service ellenőrzi a feltételeket. ! jük -, ebből egy olyan usertábla, ami a házi- 


a kondíció létrehozásánál több jellemzőt kü- ! " On Change - Log only. Amikor a ! rendünknek megfelel, és tbl " betűsorozattal 


lönböző facetekből használhatunk fel, így Kondíciókban leírtakkal ellentétes ese- ! kezdődik a neve. A hibás soroknál megte- 


MÁRCIUS-ÁPRILIS 15 






ld SAW HL NA c Ne 





LTYEEYTTTT SOL Server Management Studio 
File Edit View Project Tools Window — Community Help 


Sör Úy [dd tö 51 (3 ) ez a4 24 [d 4 nb 3 g 











A job futásáról két forrásból is tudunk tá- 
jékozódni. Az egyik a , klasszikus" job histo- 












ersary 8 ran ú ja Upen Policy - Hogy TET a táblát :zJolxi 
Objet Explor 















































































Dec1 0 Ready ry, ahol látjuk, hogy sikeresen lefutotte. A 
jpdld Select ap.ge sSsSeript v ! [dj Hebp § Ess gt. n b ib 
ganéjzt SORAN másik a házirend-kiértékelés eredménye, a 
a Name: [Hogy hívjuk a táblát 
; T enabled házirenden jobbklikk és history. [Itt minden 
ci . 
dekantn Íinnne HE] eseményt láthatunk a házirenddel kapcso- 
e T9EEESEKÉBE ÍZ Ear - Tobb latban, akár kézzel értékeltettük ki, akár idő- 
in. melyik adatlázis " Database 
zítve. Láthatjuk még az eredményt és benne 
avi azoknak az objektumoknak a listáját, ame- 
8 lyek nem feleltek meg a házirendben foglalt 
connection S feltételeknek (Condition). 
atabaso al aa lsztltááál Ha ugyanannak a házirendnek a végrehaj- 
4 (2 Legacy STARGATElarvag k kZeazte § j 
a [33 SOL Server Agent öl öntsdálámátán tási módját megváltoztatjuk On Change Log 
CEZ meeekon MOS eranyem] only módra, akkor a korábbi jobnak nyoma 
Ready 
vész (törlődik). 
Kis sz 5 ; 
2] 87 corred ll (sze els Természetesen a Házirend Historyban lát 
[down Cyeinsiasaz[ jea seezt. [jeti [docAuthor [gmesztsrt TETT — árezzemetej gyesre [gessé] mM mOJA 22 juk a futási eredményeket. Ekkor már csak a 








5. ábra. Egy SOL házirend opciói logból olvashatjuk ki, ha valamely művelet 
nem felelt meg a házirendnek. 

kinthetjük, hogy a kondíció melyik feltételé- ! (már ez is van az SOL Server 2008-ban) és Ha On Change - Prevent a kiválasztott 

vel nem egyezik a tábla tulajdonsága. meghívja a házirend kiértékelését. opció, akkor minden alkalommal, amikor 

Mi történik, ha olyan táblát akarunk lét olyan műveletet akarok végrehajtani, ami 


Evalvate- Policy -CheckSglScriptAsProxy Strue -Serverlnstance 
STARGATEVSOL2008 -Policy , Hogy hívjuk a táblát" 


ben megtestesült finoman cizellált követek művelet visszagördítődik. Az alábbi ábrán 


rehozni, ami távolról sem elégíti ki házirend- a házirendben foglaltakat nem elégíti ki, a 


ményrendszerünket? Semmi. A tábla gond 





nélkül, sikeresen létrejön. Ha legközelebb 8: Open Policy - Hogy hívjuk a táblát 
kiértékeljük a házirendet, akkor látjuk a táb- 
la neve mellett, hogy ez bizony nem felel meg Cila rel s ; ES script" [ [Zj Help 


És 3 E ae Re AA General 
anaziremedíiköveteltményetmek S Ezentkivültaz TAN EZZZTTT 
27 Description 


SSMS-ből is tájékozódhatunk, mert megje- Category: teszt r] 1 
löli a problémás objektumokhoz vezető utat. Description: visszaemlékezéseink első osztálykirándulásúnkróll 

Bejelöli a kritikus objektumokat, amelyeket 
az explorer detailsben is láthatunk a Policy 
Healt State oszlopban. 

Ha azt látjuk, hogy ez így jó, akkor akár ex- 
portálhatjuk is a policyt xmlfájlba. Később 
ezt más szerveren importálhatjuk. Ezzel meg- 
valósítható, hogy egy tesztrendszeren kikísér- 
letezett házirendcsomagot az éles környezet 


be vissza lehessen tölteni. 


4 , 
Időzítés 
E EZNBLÉT E Connection 
Fentebb utaltunk rá, hogy időzítést lehet 
v e , . 8. e (A , Server: ee. 
hozzárendelni a házirend kiértékeléséhez. STARGATEISOL2008 Additional help hyperlink: 


Készíthetünk szokásos időzítést, amit az S Connection: Text to display: [Hát ez nem lesz így jó, az alábbi linken megnézheti hogy H 
STARGATElarvag : 
Agent fog lefuttatni (persze csak akkor, ha I : : Address: [http:/ferww.asphungary.hu Test Link 


29 View connection properties 
fut a szolgáltatás). Felhasználhatunk meglévő 


időzítéseket is, amelyek a Pick nyomógombra Í Date created:  2008.03.31., 3:30 
181] té j Createdby: — STARGATElarvag 
[ds LETE Date modified: 2008.04.15. 17:29 


Ha ez megvan, akkor megnézhetjük, Modifiedby: — STARGATElarvag 
hogy létrejön egy új job, amelynek a neve a 
CHECK házirendnév forma alapján képző- 
dik. Ha belekukkantunk, akkor egy lépése 
lesz: Evaluate Policy a típusa Power Shell 1! 6. ábra. Segítség a házirendek kategorizálásában 








[8 [fekete Le TNÍi 
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szándékosan egy olyan táblát hoztam létre, 
aminek a neve nem tbllel kezdődik, ebben 
az esetben a mentés, azaza CREATE TABLE 


utasítás hiúsult meg. 


Melyik opció mikor jó? 

Néhány gondolatébresztő tipp, bár ezek után 
sokakban számtalan ötlet fogalmazódhat 
meg. Talán azt lehetne mondani, hogy a ké- 
zi futtatás a tesztelés alatt álló házirendeknél 


hasznos, illetve előnye, hogy a log-nézetben 


akkor lehetünk könyörtelenek, és jöhet az 
On Change - Prevent opció. 

Egy nagyon egyszerű példán néztük meg 
a főbb elemeket. Rövid időn belül készít 
hetünk olyan házirendeket, amelyek a kí 
vánt beállításokat ellenőrzik, a nem kíván- 
takat pedig akár online megakadályozzák. 
Fejlesztők akár ellenőrizhetik, hogy minden 
táblán van-e elsődleges index, van-e a táb- 
lában olyan oszlop, amelyben azt rögzítjük, 


ki, mikor módosította a táblát, van-e neki 








K.]" s Evaluate Policies - Hogy hívjuk a táblát 




































































G Policy Hogy hívjuk a táblát" Check Completed 
HSd select a page I E Scrot v! [/jHep 
"1 General 
T -lol.xl 
Source: [ETARGATESOL2008 
Palides: [7 ] andor / Resuk ) Field ! Operator / Expected Value — ! Actual value 
TT TPaky p [93 9 ewame LIKE tbits csunya tbl 
I AND 2 GlsSystemobiedt Iz True False 
Results: 
Select a policy to see the detailed results ín the tat 
Policy descnption: 
isi 
CZZZZEZTEZTNT MESÉS 
Target detaiis 
Server: 
STARGATEISOL2000 ) Server Ha 
ze JI STARGATC1SOL2000 Is 
STARGATEJarvag OJ STARGATCISOL2000 főerveriSTARGATCISOL2000/Dat. . , 
43 view connection properties ESEL Lal s eles 156 RGATESOL200 
Done 
w) Fxport l ! 
szesz 
; 
§ —dse [e ] b 


Ay srart] CI cAMunkat sal... [ ejsa Server 2... 2) Tartalom docx.. ] (ÁL NTA SZTAKI: ... Í (E The German C... da Microsoft SOL -- [3 Evaluate Poli... 1 névtelen - Paint [ (E Microsoft Pow... ] 4 open Policy, G... ) Hul az 0:16 

















7. ábra. Egy házirend kiértékelésének eredménye 


egy csomópont alatt áttekinthetően láthat 
juk az összes objektumot, amelyek megfe- 
lelnek, illetve azokat, amelyek nem felelnek 


meg a kritériumoknak. 


megfelelő default értéke. Adminisztrátorok 
ellenőrizhetik a már korábban említett in- 
dexstatisztikákra vonatkozó beállításokat, 


megakadályozhatják, hogy ezeket valaki meg- 














slllNew Guery 


Connectv 39 39 m T [2] 900 








3 Databases 
TA System Databases 


,/ Object Explorer Details 


STARGATEISOL2008 (SOL Server 10.0.1300 - STARGATEJarvag)iDatabasesi SOLZOOSCOCITab. , , 


2] 






Schema — [Owner — [ create... ] Policy Health state] 





E CA Database Snapshots [System Tables STARGA...  2008.03... 
E) [a Adventureworks 54 A csunya. tbl dbo 2008.03... — Critical 
. úl ReportServer 4 A Employee dbo 2008.03...  Critical 
ReportServerTempDB 54 A rossztable2 dbo 2008.04... — Critical 
a sál SaL2008cDC A tb jo dbo 2008.03... 
(Ca Database Diagrams ő4 A termek dbo 2008.04.,, — Critical 
a óda Tables 4 A xx dbo 2008.04... — Critical 


MA System Tables 
ág dbo.csunya tbl 
4 Ed dbo.Employee 

4 d dbo.rossztable2 
A dbo.tbi jo 

ága dbo.termek 
s d dbo.xxx 














8. ábra. Szépen látszik végig a fában, hogy hol van probléma 


Az On Change Log only esetén időrend- 
ben láthatjuk, mi történt. Ez jó, ha a legutol- 
só hibákat akarjuk látni, illetve ha nem akar- 
juk megakadályozni a nem kívánt műveletet. 

Ha szigorúak vagyunk, és már teszteltük a 


beállításokat egy éles, üzemelő rendszernél, 


MÁRCIUS-ÁPRILIS 


változtassa a recovery-modellel együtt. Ha vé- 
giggörgetjük a facetek jellemzőit, akkor ren- 
geteg ötletet összeszedhetünk arra, hogyan 
lehet hatékonyabban adminisztrálni az SOL 


Server 2008-at. 
Ahogy a bevezetőben említettük, persze 


4 
N/ ] 


ea] 


EE 


p) 
CAN 


K 


( see] 


ezek jó részét eddig is megtehettük volna, de 


Csak programozással 


Többszerveres adminisztráció 

Fentebb utaltunk rá, hogy exportálni tudjuk 
a házirendeket xml-fájlba, és ezeket impor- 
tálni is tudjuk más szerverre vagy szerver- 
csoportba. A regisztrált szerverek alatt talál 
ható egy Configuration Servers mappa, ez 
alá regisztrálhatunk egy szervert, a szerver 
alá több szervercsoportot, a szervercsoportok 
alá pedig egyéb szervereket. Ezzel csoporto- 
síthatjuk az adminisztrálandó szervereket. 
Minden egyes szervernél lehetőség van házi 
rendimportra, -kiértékelésre, de ezen kívül a 


Konfigurációs szerveren is megtehetjük ezt. 


Mi van mögötte? 

A DMEF mögé DDL trigger van bújtatva, 
amely szerver;, illetve adatbázisszintű esemé- 
nyekre figyel (hogy melyekre, az az általunk 
beállított házirendektől függ). Ha nincs beál 
lítva házirend On Change kezdetű opcióval, 
akkor nem jön létre DDL trigger. Ha készí- 
tünk egy házirendet (policy), akkor a házi 
rendhez tartozó kondícióból kiderül, melyik 
facetet használtuk fel. A facet tulajdonságá- 
ból pedig kiderül, hogy melyik eseményre 
(eventre) kell figyelnie a DDL triggernek. 

A DMF motor az SOLCLR-ben fut, akkor 
is, ha az adott példányban nincs engedélyez- 
ve az SOLCLR. Az SOLCLR-nek ugyanis 
két üzemmódja van: On és Off. Off mód- 
ban a Microsoft által aláírt és feltelepített 
Assemblyk futhatnak, tehát működik a ked- 
venc DMEünk. 

Kicsit részletesebben (lábvíz, mélyvíz he- 
lyett). A cikken végigvonuló nem túl bo- 
nyolult példa esetében, ha egy házirend lét 
rehozásakor On Change Log only vagy On 
Change - Prevent opciót választottuk, akkor 
létrejön a Server objectsiIriggers konténer- 
ben egy syspolicy. server. trigger. 

Ha belepillantunk, akkor látjuk, hogy 
egy speciális felhasználó nevében fut, ez a 
HHMS. PolicyEventProcessingLoginttt. A 
Master és az MSDB adatbázisban található 
meg adatbázis-felhasználóként. Ez utóbbi az 
érdekes, itt tagja a PolicyvAdministratorRole 
szerepkörnek - talán nem véletlenül. Ennek 
a szerepkörnek execute joga van a háziren- 


XXX 


deket kezelő sp. syspolicy """ tárolt eljáráso- 


kxXKK 


kon. Ezenkívül select joga van a syspolicy 


kezdetű nézeteken. 


A 
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CREATE TRIGGER [syspolicy. server. trigger] ON ALL SERVER 
WITH EXECUTE AS "zéZEMS  PolicyEventProcessingloginzé 7£" 
FOR ALTER TABLE CREATE TABLE RENAME 
AS 
BEGIN 
DECLARE (Devent data xmi 
SELECT (event data — EVENTDATA) 
EXEC  [msdb].[dbo].(sp. syspolicy. dispatch event) 
event data — (Nevent data, (Osynehronous — 1 
END 


Ezeket a nézeteket használhatjuk arra is, 
hogy a meglévő házirendeket és kondíciókat 


scriptből lekérdezhessük: 


select " from syspolicy policies 
select " from syspolicy. conditions 


De nézzük tovább a triggert! Látható, 
hogy egy jól nevelt DDL triggernek megfe- 
lelően ALTER TABLE, CRAETE TABLE, 
RENAME eseményekre gerjed. Azért csak 
ezekre, mert csak egy működő (engedélye- 
zett) házirendünk van, és annak a kiértékelé- 
séhez ezek az események elegendőek. 

Aki már látott DDL triggert, annak isme- 
rős lehet, hogy a, EVENTDATAÓ függvény 
adja vissza xmlben az esemény jellemzőit 
(milyen utasítás, mikor, process id stb.). Ezt 
átadja a sp syspolicy dispatch event tárolt 
eljárásnak, azzal együtt, hogy ez szinkron va- 
la. Az eljárást az MSDB adatbázisban talál 
juk. Most humanitárius okokból nem másol 
nám ide, bár kétségtelenül telne vele az oldal, 
és növelné a cikk tudományosságát. Ehelyett 
olcsó népszerűségből fakadóan csak felvázo- 
lom, hogy mit csinál; kibogarássza az xml 
adatból az esemény típusát, az adatbázis ne- 
vét, az objektum nevét, típusát a különböző 
fent említett nézetekkel, táblákkal összefűzve 


beszúrja az msdb.dbo.sys- 


DA 


5 DE 





EG Log File Yiewer - STARGATE) SOL2008 





DIX! 





(Eg Loadlog rédExport (élRefresh 5 Filter... G Search... [Help 
a Job Hist 
sz Polcy Hiztogy Log file summary: No filter applied 
Hogy hívjuk a táblát .Polioy Name Target 
E [I SOL Agent H€9 2008.04.15. 16:15:55 .! Hogy hívjuk a táblát 








DO 2008.04.15. 16:... . Hogy hívjuk a táblát . /Server/S TÁRGATESSOL200S/Database/SOL200SCDC/T able/dbo.Employee  — AOperatop 

o 2008.04.15. 16:... . Hogy hívjuk a táblát. /Server/STÁRGATESSOL200S7Database/SÜL2008CDC/T ableZdbo.csunya  tbl KÜ Dperatop 

€2 2008.04.15. 16:... . Hogy hívjuk a táblát . /Server/STÁRGATESSOL2008/Database/SOL200SCDC/T able/dbo. xxx cOperatop 
€22 2008.04.15. 16:04:05 Hogy hívjuk a táblát 
H €2 2008.04.15. 0.36:43 Hogy hívjuk a táblát 
E 622 2008.04.15. 0.36:40 Hogy hívjuk a táblát 
ÉVA )nnana 15 n33-n2 Hnan hísziuk a táhlát 





Selected row details: 
EE Date 2008.04.15. 16:15.55 


Policy History (Hogy hívjuk a táblát) 
Last Refresh: ő neki 
Hogy hívjuk a táblát 
2008.04.15. 16:44:02 


Filter: None 


"pr View filter settinags 


v Done (15 records). 
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9. ábra. Részletes napló a megfelelőségről 








bis Window — Community Help 


F eaz dj 2 B B 


SZA [ /TARGATENSOL2... dbo.Table 1") Object Explorer Details. [/ STARGATEISOL...SOLOuery5.sal. [/ not connected - SOLOuery3. sal 








—]. commName  [/Octatype — [/ Alowtuls az 
haj El ugyfelid int V 

Hi JEAN nyarchar(50) F ee ézet encountered during the save process. Some database objects were 

DI 


Sesserereesesereme mesz erererz eresze nez eteters eresze etéren 





"ugyfel table 
- Unable to create table, 
The transaction ended in the trigger, The batch has been aborted, 


errttizda ti 3 
kj 


Enter a name for the table: 


zi 


Save Text File [ 








10. ábra. A házirendnek nem megfelelő utasítás nem hajtódott végre 


Let ad vissza, akkor Rollback. Na végre! Már 


úgyis elvesztettem a fonalat. 


patch event tárolt eljárás 2 syspolicy. execu- 
tion, internal tábla 2 syspolicy execution 
Tehát DDL TIrigger 2 sp syspolicy dis- ! trigger 2 sp syspolicy execute policy tárolt 


eljárás 2 sys.sp. execute policy. 





policy. execution. internal 
táblába. Naná, hogy ezen 


is van egy trigger, ami sys- 





policy execution trigger 

néven fut. Ez szépen elő- 
szedi a frissen beszúrt re- 
kordokat az előző táblából 
egy jó kis cursorba, és át 
adja a sp. syspolicy. execu- 
te policy tárolt eljárásnak. 
Persze, ha hiba van, ak 
kor Raiserror. Ez az eljárás 


meghívja a sys.sp. execute 





policy eljárást, ez ellenőrzi 


a házirend feltételeit, és ha 


R. 


Registered Servers 7 UNA 
(ua a a a 
EB (a Database Engine 
CA Local Server Groups 
D ad Configuration Servers 
a ád BEREYSETETE 
HB [d Server Group 1 


IT. ábra. A házirend a Konfigurációs szerveren is ellenőrizhető 


xi Még egyszerűbben: a DDL jellegű trigge- 
rek karon fogva néhány tárolt eljárással az 
MSDB adatbázisból dolgozzák fel az esemé- 
nyeket, felhasználva az MSDB adatbázisban 


tárolt házirend-definíciókat. 





New Őuery 
Object Explorer 
Evaluate Policies. , . 


Import Policies, , , 


Van kedvünk ezeket inkább kézzel megír- 


(8) STARGATE ni? Ugye, nincs, mert hát lustaság a fejlődés 





motorja... Iehát megint nem vajákosságról 


van szó a háttérben, hanem a meglévő eszkö- 


MERESELYEK klettl A zök jól átgondolt hatékony alkalmazásáról. 
New Server Registration. , , I ll: 
—— o ] ] Az eredmény pedig? Egy hatékony adminiszt 

Tasks b 


rációs keretrendszer. 





Árva Gábor 
(Arva. Gabor Dasphungary.hu) 
MCSE, MCT, MCTS, Számalk 


Configuration Server Actions b 


——— 


Microsoft TechNet 





E CÍMLAPON 





(mlEil Xx 


TÚL A RELÁCIÓS 





VILAGON 





Fejlesztői újdonságok és új adattípusok. 


z SOL Server 2008 folytatja az építkezést azon az alapon, amit az SOL Server 2005-ös 
A verzió vezetett be, új CLR-. és natív típusokkal, valamint új SOL-parancsokkal. Ezeket 


tekintjük át a cikkünkben. 


Dátumtípusok 
Mi a probléma a meglévő DATETIME és SMALLDATETIME típusokkal? 

1. Kicsi az értékkészletük, 1753 előtt is volt már világ. 

2. Kicsi a pontosságuk, a pontosabbnak, a DATETIME-nak is 3 ms a felbontása. 

3. Nem kezelnek időzónát. 

4. Nincs külön csak dátum: és csak időtároló típus. Eleve, sokszor csak az egyik kell, például 
napra kerekített dátumtárolás, és ilyenkor nemcsak könnyebb kezelni a külön tárolt darabo- 
kat, de hely sem kell neki annyi. 

Mit kapunk hát az SOL Server 2008-ban? 

1. DATE típus. 0001-OI-01 és 9999.1231 között működik, és csak 3 bájtot foglal el. 
Értelemszerűen nap a felbontása. 

2. TIME típus. Maximum 100 ns felbontású, lehet szabályozni, mennyire legyen pontos. 
TIMEK(7) például 100 ns-os, és 5 bájtot igényel. TIMEK(0) csak 3 bájt, cserébe csak századmásod- 
percig pontos. Vagy a TIME(4) 4 bájt, és 3-4 digitig pontos (kb. ms-os felbontás). 

3. DATETIME2. Az előző kettő hibridje, 6-8 bájt kell neki, nyilván az időtag pontosságától 
függően. Ez lehet egy jó DATETIME-alternatíva, ha nagyobb pontosságra és hosszabb idősza- 
kok kezelésére van szükségünk. 

4. DATETIMEOFEFSET típus. A DATETIME2 időzónával kiegészített változata. 
Szövegként így szoktuk leírni: , 2007-05-O8 12:35:29.1234567-12:15", azaz a jelzett időponthoz 
képest plusz 12 óra 15 perc az időeltolódás. 

Hogyan látszanak ezek a típusok ADO.NEI-ből? Az SaglDblIype-ba belekerült négy új érték: 


SgiDblype.Date 
SgiDblype.Time 
SgiDbType.DateTime2 
SgiDbType.DateTimeOffSet 


Az SOL DATE és DATETIMEZ a CLR megszokott DateTime típusára képződik le. A TIME 
a TimeSpanre, a DATETIMEOFESET pedig egy új CLR-típusra a System.DatelimeOffsetté 
allaku A 


HierarchyID adattípus 
Ő egy olyan típus, amely egy hierarchia, azaz egy fa egy adott pontját tudja megcímezni. 
Hogyan lehet relációs adatbázisban fát építeni? Például rekurzív, önhivatkozó táblával, mint a 


Northwind adatbázis Employees táblája, vagy az AdventureWorks adatbázis HumanResources. 


MÁRCIUS-ÁPRILIS 


Employee táblája. Ez utóbbiban a ManagerID 
oszlop mutat a főnök EmployeelDijára. 

Az így felépített fa tetszőleges eleme jel 
lemezhető egy úgynevezett OrdPath-szal. 
Ebben a gyermekelemeknek sorrendjük van, 
mint például az xml infosetben, így a gye- 
rekek megcímezhetők a szülők alatti sorszá- 
mukkal. 1/2/4 például a gyökérnode 2. gyer- 
mekének a 4. gyerekét jelenti. 

A HierarchyID egy olyan CLR-típus, amely 
egy OrdPath-t képes tárolni. Segítségével 
igen kompakt módon lehet tárolni egy hie- 
rarchia-node helyét egy fában. Normál eset 
ben például rekurzív CTE-vel járhatunk be 
egy hierarchiát, hogy meghatározzuk az eléré- 
si útját egy node-nak. 

Ez elég lassú persze, minden szinthez kell 
egy JOIN. Egy táblában HierarchyID oszlop 
segítségével minden egyes, a fa egy node- 
ját reprezentáló sorhoz tárolhatjuk a sornak 
mint fa-node-nak a hierarchiában elfoglalt 
helyét, így rekurzió nélkül is azonnal látható, 
hol foglal helyet a hierarchiában az adott sor 
(mint node). 

A HierarchyID felfogható egyfajta denor- 
malizálási technikának is, hisz a hierarchia 
tárolható a már említett relációs módon is. 
Akár egyszerre is lehet használni a kettőt, 
de külön-külön is. Vannak esetek, amikor az 
egyik hatékonyabb, van, amikor a másik. 

Mire jó a HierarchyID? Vannak műveletek, 
amelyeket gyorsabban lehet végrehajtani a se- 
gítségével, mivel a node-ok elérési útja van 
enkódolva az idben, így a felindexelt id alap- 
ján egyes lekérdezések hatékonyak lehetnek. 

Kiinduló adatként nézzük az alábbi táb- 
lát, amely az AdventureWorks adatbázis 


HumanResources. Employvee táblájának ada- 


1 
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taiból készült (a relációs adatok hierarchikus- 
sá alakításához lásd [1]). 


SELECT OrgNode.ToString() AS LogicalNode, " 
FROM HumanResources.NewOrg ORDER BY LogicalNode; 


LogitalNode  OrgNode Empld  LoginiD ManagerD Title 


(hief Executive Offer 


/ Mód 6 did 10 Iarketng Manager 

Mo Nok 2 kem 6 Iarketing Assistant 

My GE Zoó 6 Iarketng $peciolát 

Ny 0000 22 mt Iarketing kssistnt 

)y hod 12 teni) 109 Tre Pesident of Engineering 

JN MO 3 mben 1 tngjneerng Manager 

MY koldó b0 jár ls eSigNet 

MY okok 9 mil 3 Design Engineer 

MY AMDE I ose sin Hi INET 

MY MkókET 158 ági 3 E ri a) Develonment Manager 
NY holtlőő 9 úr 198 Resegre and Development Éngneer 
ANN koMETOd TE gigjl 198 Resegnch and Development Éngineer 


Nézzük meg például, hogyan keresnénk 
meg egy adott ember összes direkt vagy indi- 
rekt beosztottját? Azaz, az adott node alatti 


részfát szeretnénk kiválasztani. 


declare caomanager HierarchyID — (select OrgNode 
from HumanResources. NewOrg 
where LoginID — "terri0") 


select 

cast(OrgNode as varchar(50)) as OrdPath, 
EmployeelD, LoginID, ManagerID, Title 

from HumanResources. NewOrg 

where Omanager.IsDescendant(OrgNode) — 
order by OrdPath 


Kikeressük terri0 HierarchyID-ját, majd az 
IsDescendant metódus segítségével leszűrjük 


az utódait. Gyerekek, unokák stb. A függ- 





PP 

















1. ábra. A Higarachyid-n létrehozott index mélységi 
bejárás alapján rendezi a hierarchikus adatokat 


vény magát a kiinduló node-ot is visszaadja, 
azaz a DescendantOrSelf talán precízebb név 
lenne. 

A lekérdezéskimenet a fenti táblázat /2/L- 
gyel kezdődő soraiból áll. 
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Az IsDescedantra fel van készítve az opti- 
malizáló, így ha Hiearchyld-s oszlopon inde- 
xet hozunk létre, akkor a lekérdezést a legha- 
tékonyabb módon, index seek-kel hajtja vég- 
re. Azaz részfa kikeresése esetén a Hiearchy[d 
sokszorosával gyorsabban szolgáltat eredmé- 
nyeket, mint a hagyományos, rekurzív JOIN- 
os eljárás. 

Ez azonban nem mindig igaz, ha például 
csak a közvetlen beosztottakat szeretném le- 
kérdezni, erre használhatom a Hiearchyld-t 
és GetAncestort metódusát. De akkor már 
lassabb lesz a lekérdezés, mint az egyszerű 
JOIN-os relációmegoldás (mivel a részfából 
ki kell szűrnie a szervernek a nem direkt gye- 


rekeket). 


select 

cast(OrgNode as varchar(50)) as OrdPath, 
EmployeelD, LoginID, ManagerID, Title 
from HumanResources. NewOrg 


where OrgNode.GetAncestor(1) — (Omanager 


De ezen is lehet azért javítani. A HiearchyId 
mélységi bejárás alapján rendezi az adatokat 
(1. ábra), ezért jó részfa szűrésre. 

Ami nekünk a direkt gyerekek hatékony 
szűréséhez kellene, az a szélességi (szintenkén- 
ti) bejárás alapján rendezett index (2. ábra). 

Ilyen index számított, indexelt oszloppal 
képezhető. Ehhez fel kell vennünk a táblá- 
ba egy új, számított oszlopot, ami a node-ok 
szintjét számolja ki (a GetLevel metódus se- 


gítségével): 


alter table HumanResources.NewOrg 
add Orglevel as OrgNode. GetLevel() 


Ez így néz ki: 


Path OrgLevel . Employeeld ManagerID 
/ 0 109 NULL 
7 ] 6 109 
JAA 2 2 6 
2 2 46 6 

JN 2 272 6 
/2/ ] TZ 109 
JAG 2 3 12 
[/DOCAUTHT 4 d 
JAY aB 9 3 
1/1471 4 79 158 


Es most jön az index a számított oszlopra: 


create nonclustered index IDX Org Breadth First 
on HumanResources. NewOrg(Orglevel, OrgNode) 
include (EmployeelD, LoginID, ManagerlD, Title) ; 


WZ 
me [ DS 
AT 


Ettől a GetAncestoros lekérdezés index 
seekre vált, azaz nagyon hatékony lesz, az új 
indexnek köszönhetően. 

A hierarchia módosításakor (példák: [2]) 
mindig frissíteni kell az érintett HierarchyID 
adatokat is, ez jelentős költséggel járhat ak- 
kor, ha a fa teteje felé kell egy node-ot új 














2. ábra. Szélességi (szintenkénti) bejárás alapján 
rendezett index 


szülő alá helyezni, azaz például egy beosz- 
tott, akinek emellett sok beosztottja is van, 
új főnököt kap. Ekkor nemcsak a beosztott 
sorában kell a HierarchyID értékét módosí 
tani, hanem az összes közvetlen és közvetett 
beosztottnál is. 

Az inkonzisztens HierarchyID-jét elkerü- 
lendő érdemes integritásvédelmet berakni a 
HierarchyID-k kezelésébe, amely azt ellenőr 
zi, hogy mindenkinek van-e szülője. Ezt elég 
egyszerű megoldani: 

Minden sorhoz képezzük a szülőt a 
GetAncestor(1) segítségével, majd egy foreign 
key contrainttel betartatjuk, hogy legyen ilyen 
szülő a primary key-k, azaz az HiearachyI[d-k 
között (feltételezzük a HierarchyID oszlopon 


van a primary key constraint). 


alter table HumanResources.NewOrg 

add Parentld AS OrgNode. GetAncestor(1) persisted 
constraint FK. Parent 

references HumanResources. NewOrg(OrgNode) 


Térbeli adattípusok 
Két térbeli (spatial) típust tartalmaz az SOL 
Server 2008: geometry és geography. A geo- 
metry hagyományos, euklidészi, derékszögű, 
sík koordinátarendszerben dolgozik, míg a 
geography elliptikus, a Földön elhelyezkedő, 
földrajzi koordinátákat modellező típus (szé- 
lesség, hosszúság stb.). 

Koordinátákkal dolgozó programok na- 
tívan tudják tárolni az adataikat, és renge- 


teg műveletet (átfedikce egymást alakzatok, 
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milyen közel vannak, stb.) értelmezhetnek 
tajt: 

A típusok különböző szabványokra épül 
nek, ezek közül a Well Known Text formá- 
tum az, amellyel szövegként írhatunk le alak- 


zatokat: 


POINT(6 10) 
LINESTRING(3 4,10 50,20 25) 
POLYGON((I 1,5 1,5.5,1 5.1 1),(2 2, 32, 33, 232 2)) 
MULTIPOINT(3.5 5.6,4.8 10.5) 
MULTILINESTRING((3 4,10 50,20 25), 
(-5 -8,-10 -8,-15 -4)) 
MULTIPOLYGON(((1 1,5 1,5 51 5,1 1), 
(232793 7377)) (886216 43 9))) 
GEOMETRYCOLLECTION(POINT(4 6), 
LINESTRING(4 6,7 10)) 


Nézzünk egy-két példát a geometry típus- 
sal. Hozzunk létre egy pontot reprezentáló 


változót: 


declare 2g geometty; 

set 2g — geometry::STGeomFromText( POINT (3 4), 
0); 
select (2g.ToString() 


POINT (3 4) 


Az STGeomFromlext a már hivatkozott 
WKI szövegből elemzi az alakzatot. Hasz- 
nálhattuk volna a specializáltabb STPoint 
Fromlext metódust is. 


Rakjuk össze a pontokat egy halmazba: 


(STUnion):declare (Da geometry — 
geometry::STGeomFromText( POINT(0 0)", 0); 

declare (ob geometry — 
geometry::STGeomFromText( POINT(4 4)", 0); 


select 2a.STUnion((2b) . ToString(); 
MULTIPOINT (4 4), (0 0)) 


Készítsünk belőle vonalat: 


select 2a.STUnion((b) .STConvexHull() .ToStringY) ; 
LINESTRING (4.4 0 0) 


Nagyon sok műveletet implementálnak 
ezek a geometriai típusok. Természetesen az 
igazi felhasználása során általában térképé- 
szeti adatokat tartalmazó táblákon végzünk 
geometriai műveleteket. Például, ha kíván- 
csiak vagyunk arra, hogy mely városok van- 


nak Magyarországon: 


select CityName from City 

where geom.STIntersects( 

(select geom from Country 

where Country Name — NHungary)) — 1 


MÁRCIUS-ÁPRILIS 


A Country táblából kiválasztjuk Magyar- 
ország körvonalát, és a városok közül azokat 
válogatjuk ki, amelyek metszik az országot. 
Nyilván persze ezt egyszerűen elővehetnénk 
egy táblázatból is, nem kellenek hozzá geo- 
metriai metódusok. De ha egy tetszőleges 
területet választunk ki, akkor már értelmes 
lehet a kérdés. 

Mely városok vannak a Duna 10 kilométe- 


res körzetében? 


declare (oDdanube geography 

select odanube — select geom from River where 
NAME — NDanube 

select CityName, 

geom.ToString() "A város koordinátái , 

geom.STDistance(odanube) Távolság a folyótól" 

from City 

where geom.STDistance((codanube) — 10000 


Az STDistance a minimális távolságot ad- 
ja meg egy pont és egy alakzat között, az- 
az leszűrjük azokat a városokat, amelyek a 
Dunától mint sokszögtől való távolsága ke- 
vesebb, mint 10000 egység. Esetünkben az 
egység méter, ami a geom nevű, geography 
típusú oszlop betöltéskor beállított vonatkoz- 
tatási rendszere miatt van. 

A geometriai típusok CLR-típusként van- 
nak implementálva, amit akár mi is meg- 
írhattunk volna. De itt nem állt meg a 
Microsoft. Sok geometriai adat kezelésekor 
ugyanis felmerül az igény, hogy indexek- 
kel szeretnénk meggyorsítani a lekérdezése- 
ket, ugyanakkor ezek az adatok messze nem 
olyan egyszerűen indexelhetők, mint mond- 
juk egy varchar vagy egy int oszlop. 


A geometriai adato- 


E oz 


cellákban van még benne egy alakzat, és me- 
lyekben nincs. Ezt a dekompozíciót max. 4 


szinten folytatják, így egyre finomabb felbon- 
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3. ábra. A spatial index egyre finomabb cellákra bontja 
fel a síkot 


tásban gyűjtenek információt az alakzatról 
(3. ábra). Hogy ne szabaduljanak el az adatok, 
vannak olyan szabályok, amelyek korlátozzák 
az adatmennyiségeket. 

Érezhető: be kell határolni a ,kockás pa- 
pír" méretét, hogy véges méretű legyen az 
index (4. ábra), erre az index létrehozásakor 
van lehetőség. Ez azonban csak a sík adatok- 
kal dolgozó geometry típusra vonatkozik, a 
geographynál véges a területünk, hisz a Föld 
felszínéről van szó. 

A geography típus ellipszoid adatainál még 
bonyolultabb a helyzet, azokat levetítik síkba, 
és úgy dolgoznak vele (5. ábra). 

A spatial index ezek után nagyon tömö- 
ren az alakzatok által elfoglalt rácspontokat 
jegyzi le. 

Mire jó ezek után egy spatial index? 
Megfelelő körülmények között az STInter- 
sects(), STEguals(), és STDistance() metódu- 


sokat meg tudja támogatni egy spatial index. 





kat indexelő spatial in- 
dex éppúgy B" fa, mint 
a közönséges indexeknél, 


csak kérdés, hogyan tud- 


ja a szerver az alakzatok ji 

adatait "úgy "átalakítani 

valamilyen bináris adat 8 s 

halmazzá, ami aztán meg- 

gyorsíthat bizonyos műve- tx-min, 
y-min 





leteket, például távolság- 





(x-max, 
y-max) 
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számítást vagy metszet 
meghatározását? 

A következő történik az index létrehozása- 
kor. A síkot vagy féltekét felbontják cellákra, 
mint amikor kockás "Dapírra rajzolunk "Az 
alakzatok ezekre a négyzetekre vannak fek- 
tetve. Minden cellát további cellákra bont 


hatunk, és ott is meghatározhatjuk, mely al- 


4. ábra. Az alakzatokat ráillesztik az előző lépésben lefektetett rácsra 


A teszteléshez a korábbi, Dunához köze- 
li településeket kiválasztó példánkat futtat 
tam, de sokkal több adatra, egy, az Amerikai 
Egyesült Államok városait tartalmazó táb- 
lán. Végrehajtási terve így néz ki spatial in- 


dex nélkül (6. ábra). 


yi 


VA 
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Látható, hogy a Filter operátor viszi el a 
költések zömét, ebben az alaptábla minden 
egyes sorára végrehajtják a szűrést. Ennek 
a Filternek kellene kiesnie vagy legalábbis a 
költségének csökkennie az index hatására. 
Index nélkül a végrehajtás átlagban 2800 ms- 
ot vett igénybe, ebből kb. 2000 ms a CPU- 
költség, azaz igen erősen processzorintenzív a 
szűrés. A lapolvasások száma 1850. 
Alapbeállításokkal hozzunk létre egy spa- 


tial indexet a geography oszlopunkon: 


create. spatial index idx USCty Spatial 1 on USCity 
(geom) 


A végrehajtási idő leesik 160 ms-ra! A lap- 
olvasások száma 1720 lett, azaz ebben nem 
mutatkozott jelentős különbség, de a CPU- 
idő leesett kb. 50 ms-ra, 2000-ről. Azért ez 
igen nagy nyereség. 

A végrehajtási terv (7. ábra). A jobb alsó 
Clustered Index Seek működik az spatial in- 
dexre építve. Azonban a spatial index csak 


közelítő index, hisz véges felbontású a rácso- 


vény (SI Distance) tényleges végrehajtásával, 
mint az eredeti 34000-ből. 

Mivel az index felbontását, azaz, hogy az 
adott térrészt mekkora részekre bontjuk, sza- 
bályozhatjuk, így egyensúlyozhatunk a pro- 
cesszorterhelés és az IO-költség között. Hisz 
ha az index nagyfelbontású, akkor nagyobb 
lesz az IO-költség, mert nagyobb lesz az in- 
dexfa, de kevesebb fals sor lesz, így kevesebb 
processzorköltsége lesz a kevesebb soron vég- 
rehajtott tényleges spatial művelet (például 
SI Distance) végrehajtásának. 

Ezt tesztelendő hozzuk létre a maximális 


felbontású indexet! 


create spatial index idx USCity Spatial 2 
on USCity(geom) using geography. grid 
with ( 

grids — (high, high, high, high) 
b 

A korábbi indexünk alapértelmezett me- 
dium felbontással jött létre minden szinten, 
ami azt jelenti, hogy minden szint 8x8-as 
Tácsra bontja az előzőt. Ez az új indexünk a 


high: miatt  16x16-os ráccsal 











dolgozik. 

Ha az előző, medium in- 
dex is rajta van a táblán, ak- 
kor a szerver nem használja 
ezt azt új indexet, mert nem 
éri meg neki. Ledobva az elő- 


zőt vagy index-hinttel ráerő- 





szakolva erre, a végrehajtási 





5. ábra. A geography típus Föld féltekéit reprezentáló koordinátáit síkba 
vetítik le 


zat, így nem tud pontos eredményeket adni. 
Ezért látható a bal alsó részben egy Filter 
operátor, amely az index által kiszűrt durva 
adathalmazt véglegesíti. Az index által le- 
válogatott adatok között ott van minden, a 
feltételre illeszkedő város, csak lehetnek ben- 
ne olyan, a feltételhez közeli városok is, ame- 
lyekre nem teljesül a feltétel. Ezeket dobja ki 
a Filter. Példánkban a bal 


idő 160 ms körül alakul, ami 
kb. azonos az előző indexelt 
megoldással. Azonban a lap- 
olvasások száma az ottani 1700-ról felugrik 
4800-ra, ami nem meglepő, hisz jóval több 
adatot tárol az indextábla. A végrehajtási 
tervben az index révén 12 sor jön vissza, azaz 
csak 2 potyasor jön ki az indexből, köszönhe- 
tő a finom felbontású rácsnak. 
Ellenpróbaként csináltam egy low, low, 


low, low durva felbontású indexet is, ebben 





oldali Merge Joinból 20 sor a 
potyog ki, valójában ennyit szet 


adott vissza az index, mivel Cost: 0 § 





durva a felbontása. A Filter 


HA gy) 


Clustered Index Scan (Clustered) 
[AdventureWorks]) . [dbo] . (USCity) . [PK... 
Cost: 24 


Filter 
Cost: 98 § 








és Nested Loop Join után 
már csak 10 sor maradt, ami 
már a helyes kimenet. Azaz igaz, hogy az in- 
dex durva felbontása miatt jöttek be felesle- 
ges sorok, de nem baj, 20 sorból mégis csak 


könnyebb kiválasztani a jókat a lassú függ- 


2 2 


6. ábra. Szűrés távolságra spatial index nélkül 


szintenként $-4-esek a rácsok. Ekkor az in- 
dex 148 sort válogat le, ebből szűrik le a tény- 
leges 10-et. Ennek végrehajtási teljesítmény- 


mutatói nagyon hasonlóak az első indexéhez. 


Valószínűleg, ha sűrű elhelyezkedésű adatok- 
ról lenne szó (például nem városok, hanem 
városon belüli házak), akkor már inkább egy 
finomabb index érné meg, a durva miatt túl 
sok adatot kellene lassú módon szűrnie a 
szervernek. 

Összegezve látható: szépen lehet játszani, 
hogy az adatok eloszlásának megfelelően mi- 
lyen felbontású indexet hozunk létre a spa- 
tial/adatainknak, így játszhatunk az (0- és a 
CPU-költség között valamiféle optimumra. 
Szép optimalizálási munka lehet ez. 


A témában részletesebb példák a [3] címen 
találhatók. 


Streaming-adatok tárolása 
Nagytömegű adatokat, például filmeket, nagy 
dokumentumokat, képeket vagy egyéb nagy- 
tömegű, strukturálatlan adatokat tárolni aka- 
ró fejlesztők számára hasznos lehet ez az új 
szolgáltatás. A VARBINARY(MAX) oszlopok 
ban, ha megjelöljük őket a FILESTREAM att 
ribútummal, akkor az adatok NEM az adat 
bázisban fognak tárolódni, hanem a fájlrend- 
szerben, sima fájlokként. Így még a 2 gigabáj- 
tos korlát is megszűnik! Nem kell most már 
azon se töprengni, hogy a nagy adataink adat 
bázisban legyenek-e vagy fájlrendszerben, ag- 
gódva a tranzakcionális konzisztencia miatt. 

Végül is mikor érdemes használni a file- 
stream store-t! 

1. Ha a tárolandó objektumok átlagmérete 
1 megabájt felett van. 

2. Ha fontos, hogy nagyon gyorsan tudjuk 
kiolvasni őket. 

3. Ha az alkalmazás rendelkezik középső 
réteggel (az adatok eléréséhez ugyanis nem 
elég a TSOL). 

Kisebb adatokhoz a sima varbinary(max) 
oszlop jobb választás lehet. 

A streamingsszolgáltatás használatához en- 


gedélyezni kell azt a szerverpéldányra: 
EXEC sp. filestream configure Denable level — 3; 


Az Oenable level azt szabályozza, hogy 
csak TSOL-ből, fájlrendszerből vagy meg- 
osztáson keresztül is láthatóak lesznek-e a 
streaming-adataink. Azaz, az adatokat közön- 
séges fájlrendszeren és megosztáson keresztül 
is elérhetjük. 

A streaming-adatokat külön file group- 
ba kell terelni, ezért eleve így hozom létre az 
adatbázist: 
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CREATE DATABASE FSTeszt ON PRIMARY ( 

NAME — FSTesztData, 

FILENAME — NGYtestSTeszt.mdf ), 

FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM ( 
NAME — FileStreamData, 

FILENAME — NCYtesAileStreamData") 


A CONTAINS FILESTREAM jelöli ki 
a speciális file groupunkat. A FILENAME 


valójában ebben az esetben nem egy fájlnév, 


majd pedig hozzárendeljük a használandó 
Sal Commandunkhoz. 
2. Beszúrjuk a stream metaadatait, a sima 


adatokat, egy inserttel, hagyományos mó- 


don, ADO.NELtel. 


insert into Kepek (Id, Name, Photo) values (Old, 
(OName, cast (" as varbinary(max))) 


Az üres stringet castoló kifejezésre azért 


CNN NR 


byte[] tranCtx — (bytel)reader[, TranCtx I; 
SafeFileHandle h — OpenSglFilestream( 
(stringyreader[,, PathName"T, 

DESIRED ACCESS WRITE, 

0, 

tranCix, 

(vint)tranCtx.Length, 

new LARGE INTEGER SAL(0)) 


Kapunk egy Handle-t, amit az interop-réteg 














mint megszokhattuk, hanem egy könyvár el ! van szükség a parancsban, hogy meg- ! egyből be is csomagol egy SafeFileHandle-be. 
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7. ábra. Szűrés spatial indexszel 


0 ete EL 0 a SERVE TE . 


érési útja, itt tárolódnak fájlokban az stream- 
adatok. 
Hozzunk létre egy táblát, ami használ 


streaming-adatokat: 


CREATE TABLE Kepek ( 

Id unigveidentifier rowgyidcol not null primary key 
default (newid()), 

Name nvarchar(256) not null, 

Photo varbinary(max) filestream null) 


Mindenképpen kell egy rowguidcol-os osz- 
lop, ez lehet PK is, vagy csak egy sima oszlop, 
de kell, ezzel tudja az adatbázis összehozni a 
tábla sorait a fájlokkal. 

Az adatokat beküldhetjük SOL-parancs- 
ként is, a megszokott I DS-csatornát felhasz- 
nálva. Azonban pont azért rakták ki fájlrend- 
szerbe ezeket a nagy adatokat, hogy NE TDS- 
en keresztül, hanem SMB-vel, a Windows 
fájlmegosztásán keresztül érjük el őket. Ez 
kicsit szokatlan, hisz használunk ugyan SOL 
INSERLet, de azért kell fájlkezelés is a meg- 
oldásban. 

Nincs managed felület az adatok kezelésé- 
re, natív API van, azt lehet használni NEC 
ből, interopon keresztül. 

A megoldás menete vázlatosan a követke- 
zőképpen alakul. 

1. Hozzákapcsolódunk a szerverhez Sglb 
indítunk, 


Connectionnel, tranzakciót 


MÁRCIUS-ÁPRILIS 


ágyazzunk az adatoknak a fájlrendszerben. 
Enélkül, ha NULL maradna az oszlop értéke, 
nem jönne létre fájl a diszken, így a követke- 
ző lépés se menne. 

3." Visszaolyassuük "att sotúnkkozet tartozó 
stream mint fájl elérési útját és egy tranzak- 
ció-azonosítót, ez kell majd a következő lépés- 
ben. Mindkettőre van egy új függvény, illetve 


metódus (kiemelve). 


select Photo.PathName() PathName, 
get. filestream. transaction. context() TranCix 
from Kepek where Id — (Old 


4. Kapunk egy natív függvényt, az Open- 
SdlFilestream-eet, azzal lehet megnyitni tranz- 
akcionálisan a streamünket mint fájlt. Mivel 


natív függvény, interopon keresztül érjük el: 


[Dillmport(, sgincli10.díl", Setlastbrror — true, CharSet 
— (harset.Unicode) ] 
public static extern SafeFilellandle OpenSglFilestream( 
string FilestreamPath, 
Ulnt32 DesiredAccess, 
Ulnt32 OpenOptions, 
pyte[] FilestreamTransactionContext, 
Ulnt32 FilestreamTransactionContextLength, 
LARGE INTEGER SOL AllocationSize 


); 


A paraméterek értékét az előző pont select 


je szolgáltatja, amit egy readerrel érek el: 


5. A Win32 handlett egy FileStream objek- 


tumon keresztül érhetjük el egyszerűen: 
FileStream fsWrite — new FileStream(h, FileAccess.Write) 


6. Most már csak írni kell az tsWrite-ba. 
Éppen ez a lényege a streamingelérésnek: 
nem összerakunk egy 34 gigabájtos objektu- 
mot, mondjuk bájt[]-öt, és odavágjuk a szer- 
vernek, hanem apránként lapátoljuk be az 


adatokat. Valahogy így például: 


int readed; 
do 


bytel! buff — new byte[4096]; 
readed — fsRead.Read(buff, 0, buff.Length); 


1 
while (reuded — 0); 


Az fsRead a helyi képre van megnyitva, 
amit fel akarunk tölteni a szerverre. 

Zárásul érdemes tudni, hogy az új, jelen- 
tősen gyorsított fulltext index megy a file- 
stream adatokra is. 


A teljes példa a [4] címen érhető el. 


Tábla típusú paraméterek 

Nem skaláris, illetve sok, nem ismert számú 
skaláris adat átadása például egy tárolt el 
járásnak elég körülményes volt eddig. Van, 


aki vesszővel elválasztott szövegbe rakta ösz- 


yt 
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sze a paramétereket, van, aki XML-ben vit 
te át a listát az SOL 2000-ben bevezetett 
OPENXML vagy az SOL Server 2005 XML- 
típusának segítségével. Mások átmeneti táb- 
lába szúrták be az adatokat, amit egy rákövet 
kező tárolt eljáráshívással dolgoztak fel. 

Az SOL Server 2008-ban egyszerűen át 
lehet adni egy tábla típusú változót a hívott 
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4. http://soci.hu/blog/index.php/2007/12/13/5g]- 
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eljárásnak. Ehhez a CREATE TYPE-ot oko- 
sították fel, ami már nemcsak álneveket tud 
létrehozni (SOL Server 7), vagy CLR-típuso- 
kat (SOL Server 2005), hanem táblatípuso- 
kat is. Például: 


CREATE TYPE LocationTableType AS TABLE ( 
LocationName VARCHAR(50), 
CostRate INT 


) 


Aztán paraméterként így lehet használni 


tárolt eljárásban: 


CREATE PROC Insertloc ( 
(Opar LocationTablelype READONLY 


) 


A Opar ezek után feldolgozható, mint 
egy sima lokális tábla típusú változó, lehet 
joinolni, insertselecttel másik táblába be- 
SZÜELSEŐ 

Az újítás legfőbb előnye, hogy egy hálózati 
körülfordulással, strukturált, típusos adato- 
kat tudunk feljuttatni a szerverre. 

Ügyféloldalon ADO.NET-ből nagyon egy- 
szerű feltölteni a táblaparamétert, egyszerűen 
egy sima DataTable-t kell adatokkal feltölteni, 


ami már direktben mehet is be a szervernek. 


Változó inicializálás deklarációkor és 
egyszerűsített értékadás 


Az declare után azonnal értéket is lehet adni 


az új lokális változónak: 


ye 


declare (2a int — 5 


A C nyelvekben már megszokott módon 
össze lehet vonni egyes operátorokat és az ér- 


tékadást egy műveletbe: 
set Da -- — 4. ob" — 4. ... 


Jól jön ez például ciklusokban, amikor nö- 


velgetni kell egy változót. 


Komponálható adatmódosító 
műveletek 

Az OUTPUT kulcsszó már ismerős lehet az 
SOL Server 2005-ből, egy DML- (INSERT, 
UPDATE, DELETE) művelet által érintett 
sorokat lehetett kirakni tábla típusú változó- 
ba vagy lokális változókba. 

A 2008-ban ezt tovább bővítették, így a ki- 
menet bemenetként szolgálhat egy INSERT 
utasítás részére, azaz össze lehet csövezni 
mindenféle átmeneti tábla nélkül a DML- 
műveleteket. Innen a komponálható DML 


elnevezés. Lássunk egy egyszerű példát: 


create table tI (col! int); 
create table t2(col1 int); 


insert into t1 values (1),(29,(3); 
insert into t2(col1) select col! from 
(update t1 set col! — col! -- 1 
output inserted.col1) as d; 


select " from t2 


col] 


ság út zóT 


Egyszerűen nevet kell adni az output kime- 
netének, és máris táblaként kezelhetjük. 

Lássunk egy összetettebb auditálást meg- 
valósító példát: 


CREATE PROC InsertLoc ( 
(par LocationTablelype READONLY 


) 

CREATE TABLE Stock (Stock VARCHAR(10) PRIMARY KEY, 
Oty INT CHECK (0ty — 0); 

CREATE TABLE Trades (Stock VARCHAR(10) PRIMARY KEY, 
Delta INT CHECK (Delta c— 0)); 

CREATE TABLE AuditChanges (Action varchar(6), Stock 
VARCHAR(6), Oty INT); 

G0 

INSERT Stock VALUESTMSFT, 10), (BOEING, 5); 
INSERT Trades VALUESTMSFT, 5), (BOEING, -5), (GE, 
3]; 


E 02 


G0 
INSERT INTO AuditChanges 
SELECT " FROM 


( 
MERGE Stock S 
USING Trades T 
ON S-Stöck — T.Stock 
WHEN MATCHED AND (Oty -- T.Delta — 0) THEN 
DELETE 
WHEN MATCHED THEN 
UPDATE SET Oty -—- — T.Delta 
WHEN NOT MATCHED THEN 
INSERT VALUES(Stock, T.Delta) 
OUTPUT Saction, T.Stock, inserted.Oty 
) tab (action, stock, gty); 
60 


select " from AuditChanges 


Action Stock Oty 


DELETE BOEING NULL 
INSERTGE 3 
UPDATE MSET 15 


Sorkonstruktor 
A VALUES most már egyszerre több értéket 


is tud kezelni: 


INSERT INTO 2Movie (MovieRatingid, Title) 
VALUES 

(3, SAL the Movie"), 

(4. "SOL Massacre", 

(1, SOL for Everyone") 


Ugyanez természetesen működik SELECT 
parancsokban is. Jól jöhet a VALUES által 
előállított virtuális tábla, ha skaláris értékek 
ből, például paraméterekből kell röptében 


táblát előállítani. 


Zárszó 

Az SOL Server 2008 számos alkalmazás- 
fejlesztési újdonsága révén egyrészt hatéko- 
nyabbá válik az eddig megszokott alkalmazá- 
sok fejlesztése (HiearchyId, FileStream stb.), 
másrészt teljesen új, térinformatikai adatok: 
kal operáló fejlett alkalmazások írására nyí 
lik mód. Gondoljuk csak el, hogy a vekto- 
ros spatial adatok Windows Presentation 
Foundation alapú (vektoros) megjelenítési fe- 
lülettel vagy Silverlight alapú webes felülettel 
kombinálva elképesztően attraktív és infor: 

matív programok készítését teszi lehetővé. 
SOCZÓ ZSOLt 
(http://soci.hu) 
MCSD, MCDBA, ASP.NET MVP 
Research Engineer, Nvalification Development Kft. 
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SEGÍTSÉGÉVEL 


Nyolc módszer, amellyel villámgyorsan feltérképezhető 


egy vállalati rendszer adatminősége. 


z Integration Services 2008 legnagyobb újdonsága kétség kívül a most bemutatandó 

adatprofilozó eszköz lesz. Ha egy mondatban kellene megfogalmaznom, hogy mit is 

jelent az adatprofilozás, akkor azt a következőképpen tenném: az adatprofilozás az a 
folyamat, amelynek során megvizsgáljuk a forrásrendszerek adatait, azokról statisztikákat ké- 
szítünk (milyen az eloszlásuk, kitöltöttségük, mennyi a minimumuk, maximumuk, átlaguk, ...) 
és információt gyűjtünk (milyen minőségűek, mennyire tiszták az adatok és integrálhatóak-e 
az adattárházba...). 

Az adatprofilozás során találkozik először az adattárház-tervező az éles adatokkal. Ekkor 
kezd el kialakulni benne egy kép az adatminőségről, és a profilozás befejezésekor már elegen- 
dő információja lesz ahhoz, hogy a fizikai adatmodellt is el tudja készíteni. Minél pontosabban 
sikerül a profilozás, annál jobb képet kap a forrásrendszerekről, és annál pontosabban tervez- 
heti meg az adatmodellt. Épp ezért fontos, hogy a profilozás során minél kifinomultabb képet 
kapjon a forrásrendszerek adatairól. 

Ám a profilozást nemcsak a forrásrendszerek analizálására lehet használni, hanem az elké- 
szült adattárház adatminőségének biztosítására és ellenőrzésére is. Képzelje el a cikket olvasó 
szakember, hogy neki kell átvennie a szállítók által elkészített adattárház több száz SSIS-betöltő 
csomagját. Hogyan fogna hozzá? Egyenként megnézni biztos nem lesz ideje, ám ha megprofi- 
lozza az adattárház adatait, akkor képet kaphat a betöltési folyamtok helyes vagy helytelen mű- 
ködéséről. 

Szintén jó szolgálatot tehet nekünk az adatprofilozó taszk a betöltések előtti adathelyesség- 
ellenőrzésekre. Vajon az érkező új adatok minimuma és maximuma a tűréshatáron belül van? 
(Például: óvodások nem lehetnek 10 évesek.) Vajon ki vannak töltve az extraktumokban (érke- 
ző forrásadatokban) a mezők, vagy tele vannak NULL értékkel? Az adatprofilozó taszk segít 
ségével mindezekre a kérdésekre választ kaphatunk, és már az extraktumok megérkezése után 
azonnal, jóval a betöltés megkezdése előtt képünk lehet az adathelyességről, és dönthetünk: 


elindítjuk a betöltést vagy kérünk új forrásadatot. 


MÁRCIUS-ÁPRILIS 


A forrásrendszerek profilozására eddig is 
léteztek eszközök, de most a Microsoft is ki- 
fejlesztett egyet, és ezt jó szokásához híven be- 
csomagolta az SOL Server 2008 programcso- 
magba. (Pontosabban az Integration Services 
2008-nak, az SOL Server 2008 mellé csoma- 
golt ETL-eszköznek a részévé tette.) 

Vegyük hát górcső alá az új adatprofilozó 
eszközt, és nézzük meg, hogyan támogatja az 
üzletiintelligencia- vagy adattárház-bevezeté- 
sek folyamatát, és milyen segítséget nyújt a 


forrásrendszerek felméréséhez. 


Az adatprofilozó taszk működésének 
áttekintése 
Az adatprofilozó taszk 

1. felolvassa az adatokat a forrástáblákból; 

2. elvégzi az adatok profilozását; 

3. az elemzés eredményét kiteszi egy XML- 
fájlba (vagy beteszi egy SSIS-változóba). 

A profilozás eredményét megnézhetjük 
egy erre a célra külön kifejlesztett eszköz, a 
Data Profile Viewer segítségével. 

(Megjegyzés: A Data Proftle Viewer nem ta- 
lálható meg a programfájlok között — legalább- 
is a CTP5-ös verzióban. Az alkalmazást a 
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, JoprogramfilesgalMicrosoft 


SOL ServerdOpTSBinnmy fs open 
DataProfileViewer.exe" 

könyvtárból kell kézzel elin- EI NEG 
dítani.) Ápproszimate 


Approximate 


Milyen vizsgálatokat 


vég ezhetü n k Length Distribution 
az adatprofilozó Length 
taszkkal? 


A most következő fejezetek: 
ben végigmegyünk az adat 
profilozási módszereken, és 
megvizsgáljuk, hogy melyik 
módszert mire lehet hasz- 


Mali a oyakonatoane 





Adathosszeloszlás- 
elemzés (Column 
Length Distribution) 





z column Lenath LDistributian FroFile - 
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1. ábra. Adathosszok eloszlása (Column Length Distribution) 





IgmereT railina 
apacez 


LÜNÜ Row: 


(illetve meg kell nézni, hogy 
új hány ismétlődést tartalmaz, 
és ebből el lehet dönteni, 
hogy kulccsá tehető-e vagy 
sem). 

Az eszköz lehetőséget biz- 
tosít összetett kulcsok kulcs- 
- képesség-vizsgálatára is. 

1.A55ŰZ 
26155 Z 
21.El21 A 
b2.J0dŰ 
0.35330 £ 
a.BÜ1TÜZ 
1.791 £ 
0.Ü10Z z 


Kitöltöttségvizsgálat 
(Column Null Ratio) 

A kitöltöttségvizsgálat ta- 
lán a leggyakrabban alkalk 
mazott adatprofilozási mód- 
szer, melynek során meg- 
vizsgáljuk, hogy egy oszlop 
hány NULL értéket tartal 
maz (az oszlop hány százalé- 
IN EE e 


A forrásrendszerek oszlo- 








Az adathosszok vizsgálatá- 
val az a célunk, hogy meg- 


Egact / 
Approximate 


nézzük, milyen a forrásosz- 
lopban tárolt adatok hosszá- 
nak eloszlása. Ezt két okból dpproximate 
tesszük: 

I9 ha mincs intormaciónk 
a forrásrendszerek adattí 
pusairól és hosszáról (mert, 
mondjuk, csak egy szöveg j 
fájlt kapunk), akkor csak ez 
alapján fogjuk tudni megha- 
tározni, hogy az adatmodell 
ben az adott mező milyen 


széles legyen; 





2. így ellenőrizni tudjuk, 
hogy megfelelnek-e a feltéte- 
lezett hossznak az adatbázis- 
ban tárolt értékek. 

Mondok egy példát: ha az irányítószám- 
mezőben van 6 karakter hosszú és 3 karakter 
hosszú mező is, akkor biztos, hogy a forrás- 
rendszer nem validálja az irányítószámokat, 
és valószínű, hogy az adattárházba töltés előtt 
tisztítani kell őket. 

Korábban ezt Min és Max értékek levá- 
logatásával ellenőriztük, de ezek a számok 
nem adtak felvilágosítást arról, hogy nem 
megfelelő az adatminőség, akkor mekkora 
a gond (azaz például az összes irányítószám 
hány százaléka 6 jegyű). Erre ad most megol 
dástaz s9lS adatprotilozó taszkja. 

Lefuttatva az AdventureWorks Address 
táblájának PostalCode oszlopára az adat 


ya 


Fatterri Distritukian 


column Fattern ProfFile - Rendszam 








at Message 





2. ábra. Patternanalízis 


hossz-eloszlás vizsgálatát azt kapjuk, hogy az 
összes PostalCode 63 százaléka 5 számjegy 
hosszúságú (2-es minimum- és 10-es maxi- 
mumértékekkel). Nem ismerem az amerikai 
irányítószámok rendszerét, de ha ez magyar: 
országi példa lenne, akkor erősen el kéne 
gondolkodnunk a forrásadatok megbízható- 


ságán... 


Kulcsképesség-elemzés 

(Candidate Key) 

Az adatprofilozó taszkkal megvizsgálhatjuk, 
hogy egy kulcsnak gondolt oszlop tényleg al 
kalmas-e kulcsképzésre vagy sem. Ha ismét 
lődő elemeket tartalmaz, akkor saját maga 


nyilván nem lehet kulcs az adattárházban 


1000 Riors . Hl 
Falttern ] Pattern Percerittage 


piLHpiLrspiL duda 


painak kitöltöttségét vizsgál 
juk például akkor, amikor 
dimenziók — attribútumait 
tervezzük. 

Mondok egy példát: Te- 
gyük fel, hogy a vevőtörzs- 
nek a forrásrendszer doku- 
mentációja szerint van olyan 
oszlopa, amely a vevőcsopor- 
tokat tartalmazza. Első ráné- 
zésre ebből érdemes lesz att 
ribútumot építenünk, igaz? 
Sőt, a fejünkben már kör 
vonalazódik egy vevő-vevő- 
csoport hierarchia is... Ám 
teljesen felesleges a vevőcso- 
portra attribútumot vagy hi- 
erarchiát építenünk, ha an- 
nak kitöltöttsége nem éri el a 10 százalékot. 

A kitöltöttség vizsgálatakor azonban nem- 
csak "azt ökellevizssálnúnk "hogy daz töszlöp 
hány százaléka tartalmaz NULL értéket, ha- 
nem azt is, hogy hány százaléka tartalmaz 
üres sztringet. Sajnos ez utóbbi keresését az 


eszköz aktuális verziója nem támogatja. 


Mintakeresés 

(Pattern Analysis) 

Na ez egy érdekes cucc. Nem csinál mást, 
mint kiszedi az oszlopból a mintákat. Megné- 
zi, hogy milyen mintát húzhat rá az adatokra, 
és ezeknek a mintáknak az eloszlását vizsgál 
ja. Mindjárt mondok egy példát, hogy érthe- 
tőbb legyen. 
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Csináltam egy demótáblát, és feltöltöttem 
ABC-123 formátumú rendszámokkal (persze 
tettem bele egy-két hibát. Például: ABC123, 
ABC 123, ...). Megprofilozva ezt az oszlopot, 
a következőt kaptam: 

Három betűből, kötőjelből, három szám- 
ból áll a rendszám az oszlop összes elemének 
92 százalékában. A maradék nyolc szálalék 
nem felel meg a szabálynak (2. ábra). 

A mintakeresés segítségével validálhatjuk 
például a telefonszámokat is. Hány százalé- 
kuk tartalmaz körzetszámot, hány nem, hány 
tartalmaz kötőjelet, szóközt, pluszjelet, hány 


nem stb. 


Oszlopstatisztikák (Column statistics) 
Megmutatja az oszlopról, hogy mennyi a 


u minimuma; 


title található, és ezek eloszlása olvasható le 
a 3. ábrából. 


Osszefüggés-elemzés 
(Functional Dependency) 
Az összefüggés-elemzés elvégzésével arra a 
kérdésre kapunk választ, hogy egyik oszlop 
elemei mennyire függnek a másik oszlop ele- 
meitől. Használhatjuk ezt a módszert hierar- 
chiák keresésére vagy hierarchia-hipotézisek 
tesztelésére. Mondok egy példát: Egy mun- 
katársnak csak egy főnöke van, vagy esetleg 
lehet több is? Ha csak egy van, akkor épít 
hetünk belőle hierarchiát, ha több van, ak 
kor nem. 

Az  összefüggés-elemzés támogatni fog 


minket az OLAP-adatmodell tervezésénél is. 


CNN s NR 


ressünk két tábla között, vagy kapcsolatok 
erősségét és irányát vizsgáljuk. Különösen 
akkor lehet nagy hasznunkra ez az elemzés, 
ha a forrásadatok szövegfájlban érkeznek, és 
a forrásrendszer dokumentációjából nem de- 
rül ki, hogy az adott szövegfájl melyik másik- 


kal áll még relációban. 


Összefoglalás 
Az SOL Server 2008 adatprofilozó taszkja jó 
kis eszköz. Sokat fog nekünk segíteni a for- 
rásrendszerek felmérésekor, az adattárházak 
minőségbiztosításakor vagy akár a forrásada- 
tok betöltés előtti validálásakor. 
Mindazonáltal a jelenlegi (ECTP 5-ös) ver- 
ziónak még vannak olyan hiányosságai, ame- 
lyekről érdemes néhány szót ejteni. 


Az első és talán legfon- 





un maximuma; 
m Dés ve 
m szórása. 

Amikor adatprofilozásról 
beszélünk, a legtöbb ember- d 
nek e négy mutató ugrik be, 
hiszen ezeket használjuk a 
leggyakrabban. A minimum- 
és maximumértékekből ké- 
pet kaphatunk az oszlopban 
tárolt adatok tartalmáról. Az 
átlag és a szórás pedig segí- 
teni fog nekünk az Analysis 
Services Measurejeinek mé- 
retezéséhez. 

Sajnos "a Dataiprotiline 
taszk jelenlegi (CIP5-ös ver- 
ziója) nem tud minimumot 


és maximumot számolni szö- 





veges oszlopok esetén. Ez 


Exact / 
Ápprosimate 


Freguent Value Distribhutiam (0, 10007 "a 1 
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: aj : af Message 


LÜN0N Rowvis 


tosabb, hogy az adatprofi 
lozó taszk csak SOL Server 
2000-es vagy újabb verziójú 
adatbázisokat képes profiloz- 
Oracle- 


vagy más adatbázisokat saj- 


ni. Szövegfájlokat, 


nos nem. Szintén sajnálatos, 
hogy a jelenlegi verziót még 
nem készítették fel arra, hogy 
FEBZA KK az adatprofilozás során talált 
naszd 
hazi 


02.JOZd A 


anomáliákat kommentezni, 
a profilozás eredményét va- 
lamilyen kulturált formában 
dokumentálni lehessen, és 
a döntéshozók elé lehessen 


tárni. Ehhez csak arra len- 






ne szükség, hogy a profilozás 
eredményét exportálni lehes- 
sen Word- vagy Exceldoku- 


mentumba. 





azért baj, mert az első (min) 
és az utolsó (max) szövegek 
(szavak) is sok információt elárultak az adat 
bázisban tárolt adatokról (pláne akkor, ami- 
kor az oszlopoknak nem beszédesek a neveik, 
Vagy "amikor d az röszlopban tnást " tárolnak: 


mint ami a rendeltetésük). 


Értékeloszlás-analízis 
(Column Valve Distribution) 
Az értékeloszlás-analízissel megállapíthatjuk, 
hogy hány különböző érték található az osz- 
lopban, és azoknak milyen az eloszlásuk. 
Mutatom: 

Az AdventureWorks (Sales] 


[vSalesPerson] nézetében 4 különböző job 


adatbázis 


MÁRCIUS-ÁPRILIS 


3. ábra. Értékeloszlás-analízis (Column Value Distribution) 


Ha két oszlop között látszólag hierarchikus 
kapcsolat van, de ezt az oszlopokban tárolt 
adatok nem támasztják alá, akkor felesleges 
rá hierarchiát tervezni. És ez jó, ha már a 
tervezési fázisban eldől, és nem akkor döbbe- 
nünk rá, amikor minden kész, már csak nem 


tudjuk felösszegezni a hierarchiát... 


Részhalmazok keresése 

(Value Inclusion) 

Az elemzéssel megállapíthatjuk, hogy az 
egyik oszlop adatai részhalmazai-e másik táb- 
la adott oszlopának. Remekül használhatjuk 


ezt a módszert arra, hogy kapcsolatokat ke- 


A jelenleg bemutatott 
adatprofilozó azonban még 
bétaverzióban van, így bízhatunk abban, 
hogy a végleges termékben ezeket a hiányos- 
ságokat is sikerül pótolni. Addig is érde- 
mes elkezdeni az ismerkedést az új adatpro- 
filozó taszkkal, hogy mire elkészül a végleges 
ÚneésTatone SEL micessZG0SÉVESZTŐ ETATS 
ismerjük annyira az eszközt, hogy fel lehes- 
sen mérni az adott vállalatnál az adatvagyon 
minőségét, és kialakuljon egy átfogó kép a 
forrásrendszerek helyes vagy helytelen mű- 
ködéséről. 
Kővári Attila 
(www.biprojekt.hu) 
BI-bevezetési tanácsadó, SOL Server MVP 
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AZ EGYSÉGBE ZÁRT 
ERŐ: ADO.NET 
ENTITY FRAMEWORK 








Minden fejlesztőkörnyezetnek segítséget kell nyújtania 


az adatkezeléshez. A .Net Frameworknek a kezdetek óta megvan 


a maga átgondolt adatelérő technológiája. Ez a feladat nem is 


olyan egyszerű, nem csoda hát, hogy sokféle megoldás látott már 


napvilágot. Az ADO.Net is folyamatosan fejlődik, és most eljött 


az ideje, hogy megismerkedjünk az Entity Frameworkkel. 


z alapproblémát az adatbázisok és a programnyelvek szemléletkülönbsége okozza. A 
As technológia között keletkezett szakadék áthidalását megkísérlő konstrukciókat 
szemléletmódjuk alapján három csoportra tudjuk osztani (Iransaction Script, Table 
Module és Domain Model).! Az első csoportba a legegyszerűbb megoldások kerülnek, amikor 
adatelérés közben elvégezzük a megfelelő műveleteket, ellenőrzéseket az adatainkkal. A má- 
sik csoportba azokat sorolhatjuk, amelyek a 
relációs adatbázisok táblázataira támaszkod- 
va táblaszerű objektumhalmazokkal dolgoz- 
nak. Ilyen például a Dataset megoldása, ami 
úgy néz ki a memóriában, mint egy forró 
vizes mosásban alaposan összement relációs 
adatbázis. A harmadik csoportba a kevésbé 
megalkuvó, üzleti objektum központú meg- 
oldások sorolhatók. Ez utóbbinak elvitatha- 
tatlan előnye, hogy észrevétlenül belesimul 
az OOP alapelveit elegánsan használó al 
kalmazások kódjába. Ezt célozza meg a .Net 
újabb verzióinak egyre igényesebb adatelérő 
technológiája. 
Hogy kinek melyik megoldást kell válasz- 
tania, azt (jó esetben) nemcsak a fejlesztő 
hozzáértése, szokásai alapján kell meghatá- 


rozni, hanem a fejlesztői környezetünk, esz- 








közeink által támogatott módszerek is je- 
lentősen befolyásolják a döntést. Életünk 
mindezidáig az ADO.Net és a Visual Studio 
által támogatott Dataset jegyében telt (Iable 
Module). Az ebből való kitörést a támogatá- 
sok megszüntetésével büntette fejlesztői kör- 
nyezetünk, bár a Domain Model elkötelezett 
híveinek volt lehetőségük alternatív eszkö- 
zökkel enyhíteni ezt a fájdalmat. 

Mostantól azonban házon belül is választ 
hatunk. A változás már régóta a levegőben 
van (lehet, hogy Dániában is ezt érezték?), és 
hogy ennyit kellett rá várni, talán azt jelen- 
ti majd, hogy alaposan átgondolt, könnyen 
használható eszközöket és tiszta, áttekinthe- 
tő környezetet kapunk. 

Ez a környezet az ADO.Net Entity frame- 
work?, ami a réteges építkezés jegyében rá- 
húz még pár emeletet az eddigi ADO.Net 
infrastruktúrára. Mint minden jó eszköz, az 
Entity Framework is problémák megoldásá- 
ban segít. Ezeken a problémákon végigvere- 


kedve magunkat igyekszünk megismerkedni 


Microsoft TechNet 


az SOL Server 2008 hozta új adatelérő keret 


rendszerrel. 


A sárga köves út 

A korrekt adateléréshez hat fontos lépésen 
keresztül vezet az út, ezeket tekintjük át a to- 
vábbiakban. 

Ha két különböző struktúra között szeret 
nénk adatot átvinni, az első probléma, amit 
meg kell oldanunk: meg 
kell határoznunk, hogy 
az egyik struktúrából 
hogyan jutunk a másik- 
ba, ez a mapping. A leg- 
egyszerűbb esetben a két 
oldal felépítése hason- 
ló, legfeljebb az adatok 
nevei, sorrendjük, eset 
leg mennyiségük külön- 
bözik. Az igazi kihívást 
jelentő esetekben azon- 
ban az adatok struktú- 
rája, absztrakciós szintje is teljesen eltérő le- 
het, miközben az információtartalom persze 
azonos. Erre a problémakörre nyújt elegáns 
megoldást az EF a háromrétegű (koncep- 
cionális modell — megfeleltető réteg — fizikai 
modell) leírással. 

Ha már tudjuk, hogyan feleltethetjük meg 
az adatforrásunk elemeit üzleti objektumaink 
tulajdonságainak, a következő kérdés az lesz, 
hogyan tudjuk ez alapján az információ alap- 
ján éppen a minket érdeklő halmazt megsze- 
rezni a háttértárból. Ez a lekérdezés. SOL ala- 
pú adatbázisoknál erre való a SELECT. Nem 
minden adatforrás SOL alapú, és ha azok is, 
köztük is van a félreértésekre elég okot adó kü- 
lönbség. Mégis ezt a lekérdezési nyelvet ismerik 
a legtöbben, és megfelelő alapot nyújthat egy 
olyan általánosításnak, amely könnyen alakít 
ható az egyes konkrét adatforrások igényeihez. 
Az EF saját SOL nyelvet használ üzleti objektu- 
mainak válogatásához. Mivel ez nem adatbá- 
zisban, hanem egy objektumorientált környe- 
zetben történik, számos olyan elemet vittek az 
Entity SOL-be, amely ezeket a sajátosságokat 
(például öröklődés, objektumtulajdonságok) 
támogatja. Bár ezt az SOL- a relációs SOL-ek- 
hez hasonlóan stringként is adagolhatjuk, sze- 
rencsére nincs rá szükségünk, hiszen a LIN€ 
pont ebben lesz segítségünkre. 

Adatokat nemcsak lekérdezni szeretnénk, 
hanem létrehozni, módosítani is (különben 


nem lenne mit lekérdezni). A harmadik kér 


ab 


dés az, hogyan tudjuk a memóriában ténfer- 
gő objektumainkról eldönteni, hogy azokat 
vajon érdemes-e átadni a háttértárnak. Sőt, 
azok a fránya háttértárak többnyire azt sem 
maguktól döntik el, hogy amit kaptak, az 
vajon új adate vagy csak valami módosítás. 
Ezt tudjuk megoldani úgy, hogy a beolvasott 


adatokat megjelöljük valami gyorsan kopó 


festékkel, így látszódik rajtuk a változás. 





Amelyiken meg egyáltalán nincs festék, az 
új. Ehhez a változáskövetéshez - hogy elég 
finoman hangolt legyen - az EF a WPF adat 
kapcsolásánál megismert PropertyChanging- 
PropertyChanged párost lovagolja meg. 

Ha idáig eljutunk a gátfutásban, már be- 
látjuk a vidéket. Hétköznapi kérdések me- 
rülnek fel. Hogyan tudjuk rávenni adatelérő 
rétegünket a tárolt eljárások használatára? 
A tárolt eljárásokat elsőre talán a teljesít 
ményoptimalizáció eszközének tekinthetjük. 
Nem kizárólag azok. Fontos szerepük van 
például az adatbázis-szerkezetünk, adatelérő 
logikánk függetlenítésében, továbbá bizton- 
sági kérdések megnyugtató rendezésében. Az 
EF mind a lekérdezések, mind az adatmódo- 
sítások során lehetőséget ad tárolt eljárások 
használatára. Meg kell azonban barátkoz- 
nunk a gondolattal, hogy ebben az esetben 
kódoldalon leszünk kénytelenek némi flexi- 
bilitási veszteséget elkönyvelni. 

Persze a mai alkalmazások olyanok, mint 
egy ogre, mert azok meg olyanok, mint a 
hagyma - többrétegűek. Ha az üzleti objek- 
tumainkat ki kell szakítanunk megszokott 
környezetükből, utaztatásuk céljából sterili- 
zálnunk kell őket. A túloldalra érve teljesen 
elvesztik a fonalat, és nem lesz olyan egyértel- 
mű a változáskövetés megvalósítása. Ennek 
megoldása lesz az ötödik problémánk. 

A végén felmerül a kérdés, hogy ez va- 


jon tényleg képes-e bármilyen adatforrással 


fla] x I 


együttműködni. De mire idáig érünk, szinte 
kizárólag visszatekintéssel megfejthetjük az 
adatforrásfüggetlenség titkát. 

A problémák közül (mapping, lekérdezés, 
változáskövetés, tárolt eljárások, többrétegű 
alkalmazások, adatforrás-függetlenség) néz- 
zük meg az elsőt. Nem csupán azért, mert 
ez az első a sorban, hanem azért is, mert ez 
egyúttal - az Entity Data Model megismeré- 
se közben - a megoldás lényegét is feltárja 


számunkra. 


Az első probléma: a két világ közötti 
tolmácsgép (ORM") 





aspnet Users User 
Applicationld Class 

$ Userld § 
(Úsz Naine 7 Properties 
LoweredUuserName áf Id 
MobileAlias a IsAnonymous 
IsAnonymous 4 LastActivity 
LastActivityDate a Name 




















Az objektumorientált és a relációs világ kö- 
zötti adattranszformációnak ideális esetben 
az alkalmazásunk irányából teljesen el kell 
tüntetnie az adatbázisok szerkezeti sajátossá- 
gait. Nézzünk rá egy példát. 

Kiindulási adatbázisunk legyen az ASP. 
Net autentikációs adatbázisa. Ezt könnyen 
előállíthatjuk magunknak a Visual Studio 
Command Promptban az aspnet regsgl pa- 
rancs segítségével. Kezdjük az laspnet Users] 
táblával a munkát! Alkalmazásunk oldalán 
pedig egy osztályra van szükségünk, amit 
Usernek nevezünk el. Mint látjuk, a két ol 
dal máris különbözik, bár a mezők számának 
különbözőségétől egyelőre eltekintünk. Van 
itt elnevezési különbség, és a számszerűségük 
sem passzol, hiszen a táblázatban sok rekord 
van, de a User objektumban csak egynek az 
adatait tárolhatjuk. Ha az alkalmazásunk- 


ban ilyen osztályokat szeretnénk használni, 


Egyszerűsítve 


A cikkben szereplő kód- illetve XML-részletek nem 
teljesek, néha le vannak egyszerűsítve az át- 
láthatóság és könnyebb megérthetőség érdekében. A 
cikkben szereplő modell egy VS projectben letölthető 
a NetAcademia honlapjáról. Ugyanott található egy 
nagyobb ábra, amely a három XML alkotóelemeinek 
összefüggéseit tartalmazza. 
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hogyan az adatok betöltéséről. 


List CUser— users — new list Users (); 


DbProviderFactory dbFactory — DbProviderFactories.GetFactory(,, System. Data. SgiClient); 
using (DbConnection connection — dbFactory.CreateConnection()) 


1 


connection. ConnectionString — (2"Data Source — .; 
initial Catalog — EFSample; 
integrated Security — rve"; 


using (DbCommand command — connection. CreateCommand()) 


command. Commandlext — (2"SELECI 


Userld, UserName, IsAnonymous, LastActivityDate 


FROM dbo.aspnet. Users"; 
connection. Open(); 
DbDataReader reader — command. ExecuteReader(); 
while (reuder.Read()) 


users. Add(new User ( 
Id— reader.GetGuid(0), 
Name — reader.GetString(1), 
IsAnonymous — reader. GetBoolean(2), 
LastActivity— reader.GetDateTime(3) 


1) 
j 
Új 
Új 


A fenti kódrészlet a teljes táblázatot be- 
tölti, éppen ezért sok User objektumra van 


szüksége (ListCUser5 ). 


aspnet Membership 
Applicationld 
$ Userld 
Password 





PasswordFormat 

PasswordSalt 

MobilePIN 

Email 

LoweredEmail 

PasswordOuestion 
PasswordAnswer 

IsApproved 

IsLockedOut 

CreateDate 

LastloginDate 
LastPasswordChangedDate 
LastLockoutDate 
FailedPasswordAttemptCount 
FailedPasswordAttemptWindo. . . 
FailedPasswordAnswerAttempt. . . 
FailedPasswordAnswerAttempt. . . 





Comment 











használatuk előtt gondoskodnunk kell vala- 





User 
Class 


z Properties 


Comment 
CreateDate 
Email 

Id 
IsAnonymous 
IsApproved 
IsLockedOut 
LastActivity 
LastLoginDate 


a 
a 
a 
a 
a 
a 
a 
a 
a 
a 


Name 











Ez a feladat annyira 
gépies, hogy akár rá is 
bízhatnánk a gépre. Ha 
valami rövid deklaratív 
módot keresünk erre 
a célra, akkor hamar 
LINÉ 


attribútu- 


rátalálunk a 
to SOL 
mos módszerére. Az a 
módszer azonban köz- 
vetlenül az adatbázis 
egy táblájához társítja osztálydefiníciónkat. 
Ennek a hátránya hamar megmutatkozik. 

Bővítsük ki User osztályunkat pár mező- 
vel. Vegyük észre, hogy az ezekhez a mezők- 
höz tartozó adatokat az adatbázisban már 
egy másik tábla, az laspnet Membership] 
tartalmazza. Az üzleti modellünkben azon- 
ban fölösleges, sőt zavaró lenne, ha két osz- 
tályt használnánk erre a célra. 

Így tehát nem elegendő osztályonként 
meghatározni a forrástáblázatot, hanem 
minden egyes property esetében tudni kel 
lene, hogy melyik táblázat melyik oszlopából 
jut adathoz. Ezt persze még mindig meg le- 
hetne valósítani attribútumokkal, de annál 
nagyobb rugalmasságot biztosító megoldást 
is találhatunk, ha ezeket az adatleképezési 
mintákat egy külön állományban tároljuk. 
A formátum persze nem lehet kétséges, hi- 
szen az XML-nek van egy olyan előnye, hogy 
egyszerű hozzá látványos grafikus szerkesz- 
tőt készíteni, ami adathierarchiák esetében 
nagyon jól fog jönni. Szóval írjuk le mindezt 
XML formátumban. 

Az EF rögtön három állományt is had- 
rendbe állított (igaz ugyan, hogy mostani 
állapotában fejlesztés közben már egy össze- 


vont fájlban található). Mi , természetesen" a 


középsővel (MSL) kezdjük. 





Az adatmegfeleltetés leírása (MSL") 
Adatbázisunkban táblázatok vannak, ezek so- 
rait tudjuk az üzleti (koncepcionális) model 
lünkben lévő objektumpéldányoknak meg- 
feleltetni. Ezek az objektumok lesznek a mi 
egységeink, entitásaink, az entitások csoport 
jait pedig EntitySetnek nevezzük, amelyek így 
aztán a táblázatokkal állnak rokonságban. I! 
Egy ilyen EntitySet neve legyen Users. Tehát 


az adatok összerendelését kezdjük így. 


2 EntitySetMapping Name— "Users z 
€/EntitySetMapping — 


Ha most a legegyszerűbb leképzést szeret 
nénk ábrázolni, akkor a következőképpen 


írhatnánk azt le. 


a EntitySetMapping Name— "Users" — 


c ScalarProperty Name — "Id" ColumnName— "Userld" 
JE 

2 ScalarProperty Name —"Name" 
ColumnName —"UserName" / 5 

2 ScalarProperty Name —"IsAnonymous" 
ColumnName — "IsAnonymous" / 5 

2 ScalarProperty Name —"LastActivityDate" 
ColumnName — "LastActivityDate" / 5 


€/EntitySetMapping — 


A kipontozott részek a további finomítá- 
sok helyeit jelzik. 

Ebből az látszik, hogy az üzleti objektu- 
munk Id propertyje (Name—) az adatforrásunk 
táblájának UserId oszlopából (ColumnName—) táp- 
lálkozhat. Egyelőre csak épp az nem látszik, 





hogy melyik az a tábla. Hát írjuk oda azt is! 


a EntitySetMapping Name— "Users" — 


a MappingFragment StoreEntitySet— "aspnet. Users" 
a ScalarProperty Name— "Id" ColumnName— "Userld" /— 
a ScalarProperty Name— "Name" 

ColumnName —"UserName"/ 5 
a StalarProperty Name — "IsAnonymous" 
ColumnName — "IsAnonymous" / 5 
a SzalarProperty Name — "LastActivityDate" 
ColumnName — "LastActivityDate" / 5 
a /MappingFragment — 


€/EntitySetMapping — 


" Mapping Schema Language, ami leírja a 
koncepcionális és a fizikai rétegek kapcsola- 
tát (C-S mapping) 


Microsoft TechNet 





Máris nyilvánvaló, hogy amelyik listát az 
üzleti modellben én Usersnek hívom, az a 
háttértáron egy aspnet Users nevű táblázat. 
Így azzal, hogy a táblázatot nem az oszlopok: 
nál jelöljük, egyrészt az ismétlődéseket iktat 
tuk ki az XML-ből, másrészt összeszedetté 
tettük a formátumot, ami a következő lépés- 
ben látható is lesz. Most ugyanis az követke- 
zik, hogy a kibővített User osztályunk adat 
mezőihez adunk útmutatást a forrásadatokat 


illetően. 


2 EntitySetMapping Name— "Users" s 


cMappingFragment StoreEntitySet— "aspnet. Users" 
a ScalarProperty Name — "Id" ColumnName— "Userld" / 5 
a ScalarProperty Name — "Name" 
ColumnName—"UserName" / 5 
a ScalarProperty Name —"IsAnonymous" 
ColumnName — "IsAnonymous" / 5 
a ScalarProperty Name — "LastActivityDate" 
ColumnName— "LastActivityDate" / 5 
c/MappingFragment — 
ca MappingFragment 
StoreEntitySet—"aspnet Membership": 
a ScalarProperty Name — "Id" ColumnName—"Userld" 
je 
2 ScalarProperty Name— "Comment" 
ColumnName— "Comment" / 5 
2 ScalarProperty Name — "LastLoginDate" 
ColumnName—"LastLoginDate" / 5 
a ScalarProperty Name —"CreateDate" 
ColumnName — "CreateDate" / 5 
a ScalarProperty Name— "IsLockedOut" 
ColumnName —"IsLockedOut" /5 
2 ScalarProperty Name — "IsApproved" 
ColumnName — "IsApproved" / 5 
2 ScalarProperty Name— "Email" 
ColumnName— "Email" /5 
c/MappingFragment— 


€/EntitySetMapping — 


Így már tisztává vált a MappingFragment 
elnevezés is, hiszen ezek között az elemek kö- 
zött a teljes adatkapcsolásunknak csak egy ré- 
sze kap helyet. Alaposabb szemlélődés közben 
feltűnik, hogy az üzleti modell oldalán az [d 
kétszer is értéket kapott! Mindkét mapping 
fragmentben egyszer. Ez szükségszerű, hi 
szen ha meg szeretnénk írni azt a kódot, le- 
kérdezést, amelyik megszerzi az adatbázisból 
a szükséges adatokat, minden üzleti objek- 
tumhoz egyértelműen meg kell találnunk 
a hozzá tartozó rekordot. Az üzleti objektu- 
munk egyedi azonosítója az [d, ezért mindkét 
táblázatban ez alapján tudunk tájékozódni. 
Ez a gondolatmenet szerencsésen passzol is 
egy jólfésült 1-1 adatbázis-kapcsolathoz, ahol 


mindkét táblának ugyanaz az elsődleges kul 


NN 


csa, és nem mellesleg az idegenkulcs-kapcso- 
latért is azok az oszlopok felelnek. 
Nagyvonalúan beszélek én itt arról, hogy 
User osztály, meg hogy üzleti objektum, 
ugyanakkor az eddig XML-be foglaltakból 
csak az összesség (Users EntitySet) látszik, de 


az egyed (User) nem. Segítsünk hát ezen is! 


a EntitySetMapping Name— "Users" s 
2 EntityIypeMapping IypeName — 
"IsSTypeOf(EFSampleModel.User)"— 
c MappingFragment StoreEntitySet— "aspnet. Users" z 
2 ScalarProperty Name — "Id" 
ColumnName— "Userld"/ 5 
a ScalarProperty Name — "Name" 
ColumnName —"UserName"/ 5 


a ScalarProperty Name — "IsApproved" 
ColumnName — "IsApproved" / 5 
a ScalarProperty Name — "Email" 
ColumnName — "Email" / 5 
c/MappingFragment — 
c /EntityIypeMapping - 
€/EntitySetMapping — 


Ezzel az új elemmel, amivel bekereteztük 
mindkét MappingFragment részt, meghatá- 
roztuk, hogy az itt leírt property-sorozat tu- 
lajdonosa az EFSampleModel.User nevű osz- 
tályunk. Ilyen osztályok sokasága alkothat 
aztán egy Users nevű listát. 

Remélem, hogy ezek alapján az informá- 
ciók alapján már mindenki tudna írni vala- 
mi egyszerű, többé-kevésbé általános adatbe- 
töltő kódot, vagy legalább belátja, hogy lehet 


ilyet készíteni. 





Trainers 
§ TrainerID 

HourlyFee 
CapacityDays 
FirstName 
LastName Trainer 

Class 

-b User 











- Properties 

a CapacityDays 
ZT FirstName 
a HorlyFee 
ZT LastName 











De miért van vajon EntitySetMapping és 
EntityIypeMapping elemünk is? Talán feles- 
legesnek tűnik, hiszen a Users listában per 
sze, hogy User elemek lesznek. Kivéve per 
sze, ha a Usernek vannak leszármazottai. 

Gondoskodjunk róla, hogy legyen. Készít 
sünk magunknak egy Trainers táblát. Lesz- 
nek az adatbázisunkban felhasználók, akik 
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közül néhányan oktatók. Csak az oktatóknak 
tárolunk egy külön táblában oktatóspecifi 
kus adatokat. Tehát egy oktató minden User- 
adattal rendelkezik, és még ezekkel a speciá- 
lis adatokkal is. Ez is egy 1-1 kapcsolat, tehát 
a TIrainers.IrainerID az tulajdonképpen az 
aspnet Users.UserID. Ha az eddigi leírást 
a meglévő EntityIypeMapping elemen belül 
egészítenénk ki egy újabb MappingFragment 


elemmel, minden  Userobjektumunknak 


lennének oktatói tulajdonságaik. De nem ez 
a cél. Hanem az, hogy legyen egy Irainer osz- 
tályunk is. Ehhez lesz szükségünk egy újabb 
EntityIypeMapping szekcióra. 


a EntitySetMapping Name— "Users" 
2 EntityIypeMapping IypeName — 
"IsTypeOf(EFSampleModel.User)"— 
a MappingFragment StoreEntitySet— "aspnet. Users" 

a ScalarProperty Name— "Id" 
ColumnName— "Userld"/ 5 

a ScalarProperty Name— "Name" 
ColumnName —"UserName"/ 5 


a ScalarProperty Name — "IsApproved" 
ColumnName— "IsApproved" /5 
a StalarProperty Name — "Email" 
ColumnName— "Email" / 5 
c/MappingFragment— 
€/EntitylypeMapping — 
2 EntityIypeMapping WypeName — 
"IsSTypeOf(EFSampleModel. Trainer)"— 
2 ScalarProperty Name — "Id" 
ColumnName — "Trainerld" / 5 
c ScalarProperty Name —"CapacityDays" 
ColumnName — "CapacityDays" / 5 
2 ScalarProperty Name —"FirstName" 
ColumnName — "FirstName" /5 
a ScalarProperty Name —"LastName" 
ColumnName —" LastName" / 5 
a ScalarProperty Name —"HourlyFee" 
ColumnName—" HourlyFee" / 5 
a /EntityIypeMapping— 
€/EntitySetMapping — 


Az kiderül, hogy ez az újabb típus az előző 
rokona (mindkettőt tartalmazhatja a Users 
EntitySet). De vajon melyik a másik ősosztá- 
lya? Úgy látszik, tovább már nem halaszthat 


juk a koncepcionális modellt leíró részt. 


A koncepcionális modell leírása 
(CSDL") 
Mint azt már sejtetni engedtem, az eddig fel 


épített XML egy háromrétegű építmény köze- 


" " Conceptual Schema Definition Language, 
ami az üzleti objektumaink KLentitásaink) 
adattartalmának és ezen objektumok kap- 
csolatainak leírását tartalmazza 


Ki 





pe. Ahogy az első ábrán is látszik, ez a középső 
réteg a két szélsőt köti össze mindenféle fur- 
fangos módon. Üzleti objektumainkat (leg 
alábbis azok adatrészét) is le kell írnunk XML 
formátumban. Ezt hívjuk koncepcionális mo- 
dellnek. Ez alapesetben egy egyszerű osztály- 
definíció. De mi máris túlbonyolítottuk, hi 
szen leszármaztattunk egy új osztályt. Nézzük 
meg, hogy néz ez ki a CSDL keretein belül. 
Induljunk ki abból, hogy szükségünk lesz 
egy User osztályra, amelyet most nem a class 
kulcsszóval fogunk definiálni, hanem XML- 
ben, és hogy ne is keverjük össze egy akármi- 


lyen típusdefinícióval, ezt entitás típusnak 


hívjuk. 


2 Entitylype Name— "User" 5 
/tntitylypez 


Ilyen User objektumból az adatbázisban 
lévő tábla sokat tartalmaz, ezért a tábla szint 


jét is definiáljuk. 


2 EntityContainer Name —"EFSampleEntities" — 
2 EntitySet Name — "Users" 
EntityIype — "EFSampleModel.User"/ 5 


€/tntityContainer— 


Itt jelent meg az EntitySet elnevezés, ami 
az MSL EntitySetMapping eleménél köszönt 
vissza. Ez itt csak egyetlen sor, és egy olyan 
kollekciót definiál, amelynek elemei User tí 
pusúak lehetnek. A típus meghatározása az 
MSL EntityIypeMapping elemében használt 
típusmeghatározáshoz hasonlóan egy névtér- 
rel együtt használja a típus nevét. Ezt a név- 
teret a Schema elemben definiáljuk, és a CH 
namespace () konstrukciójához hasonlóan 
minden beletartozik, amit a kezdő és vége 


elem között definiálunk. 


cSchema Namespace — "EFSampleModel" 
Alias—" Self" xmlns—"... "5 
a Entitylype Name— "User" 


€/tntitylype— 
c/Schemaz 


Mivel ez az XML az adatok és adatmezők 
megfeleltetéséről szól, itt csak az entitásunk 
adattagjai érdekelnek bennünket. Iehát a 


definíciónk is ehhez méltón egyszerű lesz. 


2 Entitylype Name— "User" 

a Property Name — "Id" Type—"Guid" Nullable— "false" 
1 

2 Property Name — "Name" Type— "String" 
Nullable— "false" MaxLength—"256"/5 

A Property Name —"IsAnonymous" Type —"Boolean" 
Nullable — "false" / 5 

A Property Name — "LastArctivityDate" Type — "DateTime" 
Nullable — "false" / 5 


€/Entitylype 


A pontok a többi adatmező definícióját 
jelzik, a megjelenítettekhez hasonló módon. 

A CSDL tehát definiálja az üzleti entitáso- 
kat. Az MSL pedig valójában nem a Ct vagy 
akármilyen nyelven megfogalmazott típusain- 
kat köti össze az adatforrás adataival, hanem a 
CSDL-ben definiált entitásokat a majd hama- 
rosan sorra kerülő adatszerkezetleírással. 

Szépen alakul az entitásunk, de egy fontos 
dolog még hiányzik belőle. Adathalmazokkal 
való munka során mindig tudnunk kell egy- 
értelműen azonosítani egy adatcsomagot (re- 
kordot, objektumot, entitást). Erre termé- 
szetesen egy egyedi kulcs szolgál, ami SOL 
esetében az elsődleges kulcs. Ennek megfele- 


lően itt is kulcsnak hívják. 


c Schema Namespace —"EFSampleModel" 
Alias— "Self" xmlns—". . "5 
a Entitylype Name— "User" — 
cKeyz 
2 PropertyRef Name — "Id" / 5 
ca /Keyz 
a Property Name— "Id" Type— "Guid" Nullable— "false" / 5 


€/tntitylype— 
€/Schema— 


Mint látjuk, a kulcs jelölése egyszerűen egy 
(vagy több) property-hivatkozást tartalmaz. 
És mivel egyszerű entitásunk leírása így 
már teljesnek mondható, most jött el a pil 
lanat a leszármaztatott Irainer osztály defi- 


niálására. 


2 Entitylype Name — "Trainer" Baselype —"EFSampleModel. 
Users 
2 Property Name —"HourlyFee" Type — "Decimal" 
Nullable— "false" Precision— "18" Scale— "0" 
0 
A Property Name — "CapacityDays" Type — "Byte" 
Nullable— "false" / 5 
A Property Name — "FirstName" lype — "String" 
Nullable— "false" MaxLength—"50"/— 
A Property Name — "LastName" lype— "String" 
Nullable — "false" MaxLength—"50"/— 
€/tntitylype 3 





Ebben a definícióban két jellegzetesség 
látszik. Először is: van egy Baselype attribú- 
tum, amely egyértelművé teszi, hogy ez egy 
leszármaztatás. Másodszor pedig az, ami Ct- 
ban is hasonlóan működik: csak az új adat 
tagokat kell leírni. 

Ha több táblázatból állítjuk össze a mi kis 
csomagunkat (de akár egy jó széles táblázat 
esetén is), előfordulhat, hogy a User osztá- 
lyunknak rengeteg tulajdonsága lesz, ame- 
lyek között sokkal egyszerűbb lenne eliga- 
zodni, ha valami alapján csoportosítanánk 
azokat. Ez tulajdonképpen kényelmi szol 
gáltatás, de ezért ne gondoljuk, hogy nincs 
jelentősége. Ez is, mint a többi kényelmi 
funkció, növeli munkánk hatékonyságát. A 
definiálása pedig roppant egyszerű. 

A csoportosítást (megint Ct-gondolkodás 
szerint) úgy tudjuk megoldani, hogy definiá- 
lunk egy struktúrát, amelyben össze tudjuk 
csomagolni az együvé tartozó tulajdonságo- 
kat. Az entitásunknak pedig ezek helyett a 
tulajdonságok helyett csak egy tulajdonsága 
lesz, ami azonban az újonnan definiált struk- 
túránkat tartalmazza. 

Nézzük a CSDL-oldalt. Először a csopor 


tosítótípusunk definíciója látható. 


a Complexlype Name —"Managementlype"— 
2 Property Name — "LastActivityDate" Type — "Datelime" 
Nullable— "false" / 5 
a Property Name — "IsAnonymous" Type —"Boolean" 
Nullable— "false" / 5 
2 Property Name — "IsApproved" Type — "Boolean" 
Nullable— "false" Default — "true" / 5 
a Property Name — "IsLockedOut" Type — "Boolean" 
Nullable— "false" Default — "false" / 5 
2 Property Name — "(reateDate" lype— "Datelime" 
Nullable— "false" / 5 
A Property Name — LastloginDate" Type —"Datelime" 
Nullable— "false" / 5 
c/Complexlype — 


Ami után az entitás definíciója már egyér- 
telmű, hiszen csak a kigyűjtött adatokat kell 
egy Managementlype típusúval helyettesíteni. 


2 Entitylype Name — "User" — 
2 key 
2 PropertyRef Name— "Id"/5 
c/keyz 
a Property Name— "Id" Type— "Guid" Nullable— "false" / 5 
2 Property Name — "Management" TIype — 
"Self.Managementfype" Nullable— "false" / 5 
a Property Name— "Name" Type — "String" Nullable — "false" 
MaxLength —"256"/5 
2 Property Name— "Email" Type— "String" Nullable — "true" 
MaxLength —"256"/5 
2 Property Name — "Comment" lype — "String" 
Nullable— "true" MaxLength—"3000"/-5 
€/tntitylype— 
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Azért figyeljük meg a Type attribútumot! 
A típusunk neve névtérrel van feltüntet 
ve. Ez a névtér elvileg az, amit a Schema 
elemben definiáltunk - EFSampleModdel. 
Használhatnánk azt is, de ha visszanézzük 
a Schema definíciót, akkor látunk ott egy 
Alias attribútumot, ami pont azt a célt szol 
gálja, hogy házon belül egyszerűbben írhas- 
suk ki a névteret. Így került oda a Self. 

Az ehhez tartozó MSL-oldal már egy kicsit 
trükkösebb, mert két táblázatból fogtunk 


össze adatokat. 


a EntityIypeMapping 
TypeName — "IslypeOf(EFSampleModel.Use) "— 
a MappingFragment StoreEntitySet— "aspnet. Users 
a ScalarProperty Name— "Id" ColumnName— "Userld" 
Va 
a ScalarProperty Name— "Name" 
ColumnName—"UserName" / 5 
a ComplexProperty Name — "Management" 
TpeName—"EFSampleModel. 
Managementlype"— 
a ScalarProperty Name —"LastActivityDate" 
ColumnName — "LastActivityDate"/ 5 
a ScalarProperty Name —"IsAnonymous" 
ColumnName — "IsAnonymous"/ 
c /ComplexProperty — 
c/MappingFragment — 
a MappingFragment StoreEntitySet — 
"aspnet. Membership" — 
a ScalarProperty Name— "Id" ColumnName— "Userld" 
1 


a ComplexProperty Name —"Management" 
TypeName —"EFSampleModel. 
Managementlype"— 

a ScalarProperty Name —"IsApproved" 
ColumnName — "IsApproved"/ 5 
c ScalarProperty Name —"IsLockedOut" 
ColumnName — "IsLockedOut/ 5 
c ScalarProperty Name —"CreateDate" 
ColumnName — "CreateDate" / 5 
c ScalarProperty Name —"LastLoginDate" 
ColumnName — "LastLoginDate" / 5 
c /ComplexProperty — 
c/MappingFragment — 
€/EntitylypeMapping — 


Ennek eredménye például a CreateDate 
elérésének módjában valahogy így mutatko- 


zik majd meg: 
EFSampleModel.EFSampleEntities entities — new 
EFSampleModel.EFSampleEntities() ; 


foreach (EFSampleModel. User u in entities. Users) 


Console.Writeline(u.Management.CreateDate); 


li 


(NN 


Kapcsolatok 

Természetesen az adatbázisban a tábláink, 
üzleti modellünkben pedig az entitásaink 
nincsenek elszigetelve egymástól. Sőt, talán 
az egyik legfontosabb tulajdonsága mind- 
két oldalnak, hogy kapcsolatot tud teremte- 
ni adathalmazaink közt, szép, logikus adat 
struktúrákat teremtve ezzel. Ezeket a kap- 
csolatokat adatbázisszinten az idegenkulcsok 
segítségével hozzuk létre. Objektumok eseté- 
ben viszont referenciákkal. A két technika 
erős különbségeket mutat még nedves félho- 
mályban, ködlámpa nélkül is. Mindjárt a leg- 
szembetűnőbb, hogy adatbázisnál a gyerekek 
hivatkoznak a szülőtáblákra, objektumok 
esetében ez inkább fordítva van. És mivel 
egy gyermekre így több szülő is hivatkozhat, 
roppant egyszerűen előállhat a több-több 
kapcsolat. Relációs adatbázisoknál ez a faj- 
ta kapcsolat nem tudja hiányolni a kapcso- 
lótáblát. Mivel ez sarkalatos pont egy ilyen 
rendszer használhatóságának megítélésekor, 


az ismerkedéshez nézzük meg erre az EF meg- 


oldását a CSDL-oldallal kezdve. 


a Association Name — "UsersinRoles"— 
a End Role —"RolesEnd" Type —"EFSampleModel.Role" 


Multiplicity— 9" /5 
a End Role—"UsersEnd" Type — "EFSampleModel. User" 
Multiplicity— 9" /5 
G/Association — 


Ezzel az egy Association elemmel megha- 
tároztunk egy több-több kapcsolatot, ami 
a két végpont számosságából (Multiplicity—) lát 
szik. A kapcsolatban részt vevő két végpont 
nak adtunk nevet (Role—), és meghatároztuk 
az adott oldalon helyet foglaló entitás típusát 
(Iype—). Azzal, hogy a két entitásunk közöt 
ti kapcsolatot definiáltuk, még nem tudjuk 
kódból elérni ezt a kapcsolatot. Ehhez szük- 
ségünk van mindkét típusban a másik típus- 
sal feltölthető listatulajdonságra. Ezt valósít 
hatjuk meg a NavigationProperty elem segít 


ségével az entitásaink definíciójában. 


2 EntityIype Name— "User" 


2 NavigationProperty Name —"Roles" 
Relationship —"EFSampleModel.UsersinRoles" 
FromRole —"UsersEnd" ToRole —"RolesEnd" 
I- 
c /Entitylype 3 





Hasonló módon a Role entitásban: 


2 EntityIype Name—"Role"— 


2 NavigationProperty Name — "Users" Relationship — 
"EFSampleModel.UsersinRoles" 
FromRole —"RolesEnd" 
ToRole—"UsersEnd" / 5 
a /Entitylype - 


Két nevet adtunk meg, az egyik a prop- 
erty neve (Name—), amelyen keresztül elérhet 
jük a kapcsolat túloldalán lévő objektumokat, 
a másik pedig a hivatkozott kapcsolat neve 
(Relationship—). Mivel mindkét oldalon ugyanazt a 
kapcsolatot használjuk, meg kell határoznunk 
az irányt. Erre szolgál a FromRole és a ToRole attribú- 
tum, amelyek a kapcsolatdefinícióban megha- 
tározott végpontneveket kaphatják értékül. 

Ezeknek a definícióknak az eredménye- 
képpen fogunk tudni a következő módon 


navigálni a kapcsolatainkon. 


EFSampleModel. User user; 
EFSampleModel.Role role; 


foreach (EFSampleModel.Role vserrole in user.Roles) 


Console.Writeline(userrole.RoleName); 


j 


foreach (EFSampleModel. User roleuser in role. Users) 


Console.Writeline(rolevser.Name); 


j 


Sajnos azonban ez a kapcsolat jelen állapo- 
tában még eléggé légből kapott. 

Először is egy Association-példány csak 
két entitáspéldányt köt össze, tehát az enti 
táslistáinkhoz hasonlóan definiálni kell a 
kapcsolatlistát is, a már ismert helyen, az 


EntityContainer elem alatt. 


2 EntityContainer Name — "EFSampleEntities"— 
2 EntitySet Name— "Roles" Entitylype — 
"EFSampleModel. Role" /— 
2 EntitySet Name — "Users" Entitylype — 
"EFSampleModel.User"/ 5 
2 AssociationSet Name —"UsersinRolesSet" 
Association —"EFSampleModel.UsersinRoles"— 
End Role —"RolesEnd" EntitySet—"Roles" / 5 
aEnd Role—"UsersEnd" EntitySet— "Users" / 5 
c /AssociationSet — 
€/tntityContainer— 
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Itt a végpontok nem entitások, hanem en- 
titáslisták. 

Nem határoztuk meg továbbá, hogy a kap- 
csolatot hogyan lehet kiolvasni az adatbázis- 
ból. Hiányzik tehát a középső réteg. Nézzük 


meg, mi a teendőnk az MSL-ben. 


a AssociationSetMapping Name — "UsersinRolesSet" 
TypeName —"EFSampleModel.UsersinRoles" 
StoreEntitySet— "aspnet. UsersinRoles"— 
a EndProperty Name —"RolesEnd"— 
a ScalarProperty Name — "Id" ColumnName — "Roleld" / 5 
c/tndProperty 
a EndProperty Name —"UsersEnd"— 
a ScalorProperty Name — "Id" ColumnName— "Userld"/ 5 
c/tndProperty— 
G/AssociationSetMapping — 


A párosítás most is setekre vonatkozik. 
Meghatározzuk, hogy melyik kapcsolattípust 
(IypeName—) melyik adatbázistáblából szeret 
nénk kiolvasni. Az adatbázisban a kapcsola- 
tok idegenkulcs-oszlop formájában jelennek 
meg. Egy kapcsolat beolvasása tehát ennek az 
idegenkulcs-adatnak a megszerzését jelenti. 
Több-több kapcsolat esetén ezek az idegen- 
kulcsok ki vannak emelve egy kapcsolótáb- 
lába. Ezt a kapcsolótáblát mutatjuk meg a 
StoreEntitySet attribútummal. Azelső EndProperty 
az AÁssociationSet RolesEnd végén meghatá- 
rozott Roles nevű EntitySet Id oszlopához 
rendeli a fizikai rétegben (StoreEntitySet-) 
található aspnet UsersInRoles tábla Roleld 
oszlopát. A következő EndProperty hasonló 
módon a Users nevű EntitySethez kapcsolja a 


tábla Userld oszlopát. 


Fizikai modell (SSDL") 

Az említett XML-hármasból eddig csak ket 
tőbe sikerült bepillantást nyernünk. A har 
madik sem kevésbé fontos, mégis csak a végé- 
re hagytam egy kis összefoglalót róla. Az ed- 
digiek alapján viszonylag könnyen követhető 
a felépítése. A sémában definiált névtéren 
belül találhatók az adatlistáink (EntitySet) 
definíciói, amelyeket relációs adatbázis ese- 
tében egyszerűen a táblázatoknak feleltethe- 


tünk meg (Name—). 


c Schema Namespace — "EFSampleModel. Store" 
Alias— "Self" xmlns— ". . "5 
2 EntityContainer Name—"dbo"— 


x 


Store Schema Definition Language 


2 EntitySet Name—"aspnet. Roles" 
EntityIype —"EFSampleModel.Store.sRoles" / 5 
2 EntitySet Name—"aspnet. Users" 
EntityIype —"EFSampleModel.Store.sUsers"/ 5 
2 EntitySet Name—"aspnet. UsersinRoles" 
Entitylype —"EFSampleModel.Store.sUserslnRoles"/ 5 


Másrészt itt találhatók a kapcsolatvég- 


pontdefiníciók. 


2 AssociationSet Name— "FK UIR RolesSet" 
Association —"EFSampleModel.Store.FK. UR. Roles"— 
c End Role—"FKRolesEnd" EntitySet—"aspnet. Roles"/ 5 
End Role—"FKÜsersRolesEnd" 
EntitySet—"aspnet. UsersinRoles"/ 5 
S/AssocationSet — 


Aztán az EntityContainer lezárása után 
maguk a táblasémák, vagy ha úgy tetszik, a 
tábláink egyedeit alkotó típusok definíciói, 
amelyekre a fenti EntitySetelemek Entity- 
Type attribútumai hivatkoznak. 


2 EntityIype Name — "sUsersinRoles"— 
ckeyz 
A PropertyRef Name —"Userld"/ 5 
2 PropertyRef Name — "Roleld" /— 
c/keyz 
2 Property Name — "Userld" Type — "vnigveidentifier" 
Nullable— "false" / 5 
2 Property Name — "Roleld" Type — "vnigveidentifier" 
Nullable— "false" / 5 
€/tEntitylype— 


No és persze a kapcsolatok definíciói, 
amelyek az SSDL-ben az adatbázis idegen- 
kulcsainak megfelelői. A koncepcionális mo- 
dellben található Association-elemek nem 
ezekre, hanem közvetlenül a tábla oszlopaira 
fordítódnak le. Erre itt az adatbázissal való 


kommunikáció miatt van szükség. 


a Association Name— "FK UR Roles"s 
a End Role —"FKRolesEnd" Type — 
"EFSampleModel.Store.sRoles" Multiplicity— "175 
a End Roleg—"FKUSsersRolesEnd" Type — 
"EFSampleModel.Store.sUsersInRoles" 
Multiplicity— 975 
2 ReferentialConstraint — 
A Prindpal Rolg—"FKRolesEnd"— 
2 PropertyRef Name — "Roleld" / 5 
c/Principal — 
a Dependent Role— "FKUsersinRolesEnd"— 
2 PropertyRef Name — "Roleld" / 5 
c/Dependent— 
c /ReferentialConstraint— 
C/Association — 





Ezzel a harmadik XMLIel teljessé vált a 
kép. A gyakorlatban ezek egységet alkotnak, 
és egy fájlban is találhatók (némi designer in- 
formációval együtt). Ez as EDMX file. 


Infrastruktúrátlanítás 

(vagy fordítva?) 

Ezt a rengeteg XML-t nemcsak az írás örömé- 
ért szerkesztettük (a Visual Studióval), ez az, 
amiből a kódgenerátor az alkalmazásunkban 
könnyedén felhasználható kódot, osztályde- 
finíciókat generál. Ezek is, mint minden ge- 
nerált osztály, partial classként kerülnek a 
kódba. Ezek fogják tartalmazni adatainkat, 
és ezeket tudjuk használni LINO to Entities 
lekérdezéseinkben. 

A generált kód specializál továbbá pár 
infrastrukturális osztályt, hogy a saját kör- 
nyezetünkben kényelmesen és biztonságosan 
használhassuk azokat. Ezek az osztályok szá- 
mos társukkal alkotják az Object Servicest. 
Implementációik a System.Data.Objects és 
a System.Data.Objects.DataClasses névte- 
rekben találhatók. Közülük a legfontosabb, 
központi osztályunk az ObjectContext. Ez 
felelős az adatforráshoz való kapcsolódásért, 
a metaadatokért, melyek leírják modelljein- 


ket, továbbá a változáskövetésért. 


A designer támogatása 
Természetesen létezik grafikus felület is az 
EDMX előállítására. S az is, hogy egy ilyen 
grafikus felület nem használja ki az összes 
lehetőséget - főleg, hogy még csak CIP vál 
tozatban érhető el? - de a leggyakoribb hely- 
zetek megoldásában mindenképpen segítsé- 
günkre van. Pakolhatnék ide szép képeket 
a varázslóból, de nem teszem. Azt remélem, 
hogy sikerült elég részletes leírást adnom az 
alapelvekről ahhoz, hogy a varázsló feliratai 
közt könnyedén elnavigáljunk. Vész esetén 
pedig jobbklikk az edmx-en és Open With... 
Tóth László 
(tocsi(Onetacademia. net) 
NetAcademia 


! Martin Fowler - Patterns of Enterprise 
Application Architecture 

? http://www.microsoft.com/downloads/ 
details.aspx!"FamilyId-15DB9989-1621-444D- 
9B18-DILAOS4A21BSI19Sdisplaylang-en 

3 http://www.microsoft.com/downloads/ 
details.aspx! FamilyI[d-DS8AE4404-8E05- 
41FC-94C8-C73D9E238F8S2Sdisplaylang-en 
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— INFRASTRUKTÚRA 





MENTSÜK, 


AMI MENTHETŐ! 


Minden cikknek, így ennek is van egy kis előélete. 


A cikk megírása előtt villámgyors adatgyűjtésbe kezdtem, 


és már az első félóra után látszott, 


hogy nemcsak a rendelkezésre álló néhány oldalt, hanem akár 


egy egész laoszámot meg lehetne tölteni a mentés-helyreállítás 


témaköréhez tartozó cikkekkel. 


fent leírtak még akkor is igazak, ha csak az SOL-adatbázisok és a SharePointfarmok 
mentésére koncentrálok. A cikk megírása előtt villámgyors adatgyűjtésbe kezdtem. 


Így - kompromisszumokat keresve - kötöttem ki az alább következő két témánál. 


SOL backup — for dummies 

Elnézést kérek a szerverkatasztrófákon és helyreállításokon edződött adatbázis- és SharePoint 
gazda kollégáktól. Az első fejezet nem nekik szól, kérem jó szándékú megértésüket. Inkább 
azok számára adnék - igazából csak futó - áttekintést az SOL- és a SharePointmentés szép- 
ségeiről, akik éppen most kezdenek ismerkedni a technológiával, és a legtöbb esetben szingli 
rendszergazdaként az összes többi rendszer mellett kell ezeket a nem kis komplexitású, ugyan- 
akkor az üzletmenet szempontjából egyre inkább kritikus rendszereket egészségesen tartaniuk. 
Az első fejezet tehát azoknak szól, akik az alábbi kérdések közül legalább az egyikre nemmel 
válaszolnak. (A válaszadás önkéntes, nem reprezentatív, és senki sem ellenőrzi, tessék tehát 
őszintének lenni.) 

na Pontosan tudja-e, hogy mit, milyen rendszerességgel és hogyan kell mentenie egy SOL-adat 

bázis vagy egy SharePointkiszolgáló(farm) esetén? 

ax Van-e kidolgozott módszere a felhasználói hibából eredő helyreállítási igények kezelésére 

(mint például dokumentumok törlése egy SharePointdokumentumtárból)? 

A jó hír az, hogy - a forradalmi változások előjelei ellenére - adataink továbbra is fájlok 
formájában öltenek testet a merevlemezen, és nagyrészt ebben a formájukban menthetők 
is. [gaz ez az adatbázisokkal dolgozó rendszerekre is, mint az Exchange, az SOL Server és a 
SharePoint, de e rendszerek esetén sokféle megfontolás miatt kerülőutat kell tennünk, ha meg- 
bízható mentést szeretnénk készíteni. Hogy csak a két legnyomósabb érvet említsem: az adat 
konzisztencia biztosítása és a felhasználóknak nyújtott teljesítmény fenntartása. Az Exchange 
egy külön világ - bár mentési szempontból sok hasonlóságot mutat az SOL Server mentésével 
- így koncentráljunk most az SCOOL-adatbázisokra. Mint látni fogjuk, a SharePoint annyival ár- 
nyalja majd tovább a képet, hogy ott adatbázisok és fájlok sajátos együttese alkotja a konzisz- 


tens állapotot, amely alkalmas lehet egy katasztrófahelyzetből történő visszaállításra. 


MÁRCIUS-ÁPRILIS 


Az adatbázismentésekkel kapcsolatban 
először a mentési-visszaállítási stratégia és a 
recovery modell fogalmával kell megismer- 
kednünk, mert ezek döntően meghatározzák 
lehetőségeinket. A mentési-visszaállítási stra- 
tégia egy elvi (és pénzügyi) döntés, amellyel 
igyekszünk maximalizálni az adatok rendel 
kezésre állását és minimalizálni az adatvesz- 
tés kockázatát. Egyszerűen belátható, hogy 
egy bizonyos ponton túl az adatok rendelke- 
zésre állása nem növelhető tovább az adat 
vesztés kockázata nélkül (például a mentési 
ablak nem rövidíthető a mentés lefutásához 
technológiailag szükséges idő alá). A képlet 
már így sem egyszerű, de zavaró tényezőként 
ide társul még harmadikként a költség, és ek- 
kor már komoly mérlegelésre van szükség: mi 
a helyes arány az adatbázisrendszer költségei 
(beleértve a mentési rendszer költségét), az 
adatok rendelkezésre állása és az adatvesztés 
kockázata között. Itt a döntő szót minden bi- 
zonnyal az üzleti vezetők fogják kimondani, 
de igyekezzünk döntésüket megfelelő tech- 
nológiai adatokkal és érvekkel előkészíteni, 
mert a kialakított rendszert a mi feladatunk 
lesz üzemeltetni, és rajtunk fogják számon 
kérni a vállalt paramétereket. 


Visszatérve a technológiához: az SOL 
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Server adatbázisai esetén háromféle helyreál 
lítási (recovery) modell közül választhatunk, 
ezek a simple, a full és a bulk logged. A 
simple modell alkalmazása esetén a mentés 
csak az adatbázisfájlt tartalmazza, a hozzá 
tartozó tranzakciós logokat nem, sőt ezek a 
logok időről időre (minden checkpointnál) 
csonkolódnak, hogy a logfájl ne töltse tele a 
merevlemezt. Így a visszatöltés lehetősége az 
utolsó mentett állapotra korlátozódik, a men- 
tés utáni változások a tranzakciós logok cson- 
kolása miatt elvesznek, és a visszatöltés után 
nem reprodukálhatók. Praktikusan tehát kis- 
méretű és/vagy ritkábban változó adatbázi- 
sokon alkalmazhatjuk ezt a modellt, ezeket 
az adatbázisokat kellő gyakorisággal tudjuk 
lementeni ahhoz, hogy az adatvesztés kocká- 
zata ne nőjön magasra. Teljes és differenciális 
mentések váltogatásával és a gyakoriság jó be- 
állításával már a simple modell alkalmazása 
esetén is az üzlet számára elfogadható menté- 
si-visszaállítási stratégiát készíthetünk. 

A full és bulk logged helyreállítási modelL 


nél a tranzakciós log mentése előfeltétele an- 





Database 


LL Time — 


Database backups 


Disaster 





Database restored to t5 











1. ábra. Adatvesztés a simple recovery modell esetén 


nak, hogy a checkpoint felszabadítsa a már 
feldolgozott tranzakciók által elfoglalt helyet 
a logfájlban. A folyamat pontosabb megér- 
téséhez nézzünk bele egy kicsit a logfájlba! 
A tranzakciós log az adatbázis szerves része- 
ként, azzal egy időben jön létre, és az adat 
bázis konfigurációjától függően vele együtt 
növekedhet. A tranzakciós log belül kisebb, 
úgynevezett virtuális logfájlokra oszlik, eze- 
ket a rendszer automatikusan kezeli: szükség 
esetén újabbakat hoz létre, illetve megfelelő 
feltételek esetén felszabadítja és újrahaszno- 
sítja őket. A tranzakciók sorában előrehalad- 
va újabb és újabb virtuális logfájlok jönnek 
létre. Ha ezek a virtuális logok felemésztik a 
tranzakciós logfájl által előre lefoglalt lemez- 
területet, akkor (ha az adatbázis konfigurá- 
ciója ezt megengedi) a tranzakciós log újabb 


területet foglal le a lemezen, amennyiben ez 


ki 


nem sikerül, akkor az adatbázist a konziszten- 
cia megőrzése érdekében leállítja (akárcsak 


az Exchange). 





Virtual Log2 — Virtual Log3 — VírtualLog4 — Virtual Log 5 














logical log Checkpoint logical log 





2. ábra. Tranzakciós log mentés előtt... 





Virtual Log2 — VírtualLlog3 — Víirtuallog4 Virtual Log 5 


Truncated ] 





End of 
Checkpoint . logical log 








logical log 





3. ábra. ...és után 


Vegyünk itt észre két pontot, ami üzemel 
tetési szempontból is fontos: 

1. a tranzakciós logok által használt merev- 
lemez szabad kapacitása - az adatbázist tar- 
talmazó lemezekhez hasonlóan - szigorúan 
monitorozandó; 

2. a tranzakciós logok töredezettekké vál 
hatnak, ami a teljesítmény romlását okozhat 
ja, a töredezettségmentesítést tehát tervsze- 
rűen el kell végezni! 

Amikor egy full modell szerint működő 
adatbázis tranzakciós logját mentjük, akkor 
felhatalmazzuk a rendszert, hogy a következő 
checkpointra ráfutva mindazokat a virtuális 
logokat, amelyek csak sikeresen feldolgozott 
tranzakciókat tartalmaznak, és a mentésben 
szerepelnek, szabadítsa fel, és szükség esetén 
írja felül. Üzemeltetési szempontból azt nyer- 


jük tehát a tranzakciós logok mentésével, 


Elérési út 


Program FilexxXCommon FilesWMicrosoft Shared) 
Web server extension 2 


Inetpub 


Tartalom 


EdLi 


adatvesztést, ha az adatbázismentésünk és va- 
lamennyi (! logmentésünk sikeres, és ebből 
a tranzakciós logok visszaállításával egy foly- 
tonos tranzakció-sorozatot tudunk képezni. 
A logfájlokban ugyanis minden tranzakció 
rendelkezik egy azonosítóval (Log Seguence 
Number), és ha az LSN-számok folytonossága 
megszakad, akkor helyreállításkor a tranzak- 
ció továbbgörgetése már nem lehetséges (hi- 
szen azt kockáztatjuk, hogy a hiányzó tranz- 
akciók miatt szétesik az adatbázis egysége). 

A bulk logged modellről most elegendő 
annyit megjegyeznünk, hogy használatát 
csak átmeneti időszakokra javasolják, olyan- 
kor, amikor az adatbázisokba nagy mennyi- 
ségű adatot töltenek fel, és a részletes logolás 
mellőzésével akarják javítani a feldolgozás se- 
bességét. Ebben a módban csak a hagyomá- 


nyos tranzakciók logolása történik meg, a tö- 








Central Administration Console/ 


Custom Backup Application File Server 








4. ábra. A mentendő SharePoint-komponensek 


meges feldolgozás eseményei csak minimális 
mértékben kerülnek bele a logfájlba. Ebből 
következően az ilyen állapot visszaállítása 
rendkívül körülményes. A napi gyakorlatban 
jobban tesszük, ha a full modellt használjuk, 


és csak a tömeges feltöltés idejére változta- 


Általánosan frissített fájlok, egyedi assemblyk, egyedi sablonok, egye- 
di site-definíciók. 


IIS virtuális könyvtárak. 


Global assembly cache (GAC). Egy védett operációsrendszer-terület, 


CNWINNTVassembly 


ahol a .NET Framework code assemblyk találhatók teljes rendszer- 


jogosultságokkal. 


hogy a logfájl által foglalt lemezterület kordá- 
ban tarthatóvá válik. A mentések szempont 
jából viszont nagyon fontos, hogy az adatbá- 
zismentések és a logmentések konzisztensek 
legyenek. Csak akkor élvezhetjük ugyanis 


a modell előnyeit, és minimalizálhatjuk az 


tunk a recovery modellen (ha az feltétlenül 
szükséges). 

Mint az előzőekből kiderült, a mentések 
re három módunk kínálkozik, ami a simple 
modell esetén csak kettő: a teljes adatbázis 


mentése, az adatbázisról készített differenciá- 


Microsoft TechNet 
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lis mentés és a tranzakciós logok mentése (ez 
utóbbi nem lehetséges a simple modell alkal 
mazásakor). A teljes és a differenciális mentés 
metódusa teljesen analóg a fájlmentéseknél 
alkalmazott azonos nevű eljárásokkal, így eze- 


ket részletesen nem fejtem ki. A mentések 


tv DPM 2007 Administrator Console 


juk: vagy rendszeradatbázis vagy felhasználói 
adatbázis. Az előbbieket a rendszer a telepí 
téskor automatikusan létrehozza, és nagy- 
részt önállóan kezeli is. Az utóbbiakat az al 
kalmazásaink vagy alkalmazásgazdáink (sok- 
szor mi magunk) hozzák létre, és mivel ezek 

hordozzák a cégünk 


szempontjából értéket 





File Action View Help 





alala Protection Group: File Protection (Total members: 2) 
B H Computer: WS8-DC.ws8demo.local 





BH Computer: ws8-wss31.ws8demo.local 
sa Gst Volume ego 
slag Protection Group: SOL Group (Total members: 4) 





A [d Computer: ws8-wss31.ws8demo.local 


[d WS8-WSSZIMICROSOFTé$SSEEImaster SOL Data ego 
(d W58-WSSZIWMICROSOFTé$SSEEWmodel SOL Data ego 
(d W58-WSSZIMICROSOFTé$SSEE msdb SOL Data ego 
(d WS8-WSSZ1WMICROSOFT$SSEEIWSS. Search. WS8-... SOL Data ego 














a(Bh2 Protection Group: WSS 3.1 (Total members: 1) 
B H Computer: ws8-wss31.ws8demo.local 








Group by: [Protection group sz I 





képező adatokat, na- 
gyobb figyelemmel kell 
foglalkoznunk velük. 
A felhasználói adatbá- 
zisok mentési gyakori 
ságát alapvetően az üz- 
leti igények határozzák 
meg. Lehetségesek rit 
kán változó, tehát vi 


szonylag statikus adat 


gű Sharepoint FarmiWS8-WSSZíMMicrosoftézSSEElShar. .. . SharePoint Farm 9 OK 
bázisok (például egy 
Details: GA 6. , fp. 
ügyféladatbázis),  ame- 
Status: OK 
Replica path: Cid to view detals lyeket elegendő akár 
Latest recovery point: 4/14/2008 5:02: 13 PM 
Öldest recovery point: 4/10/2008 11:34:46 AM hetente menteni (és 
Total recovery points: 11 
Disk allocation: Replica volume: 11.08 GB allocated, 5.52 GB used ] Recovery point volume: 2.30 GB allocated, 944.67 MB used mondjuk, naponként 





csak a tranzakciós logo- 





5. ábra. Amikor minden rendben van a mentésekkel 


Select Recovery Type 
Select the type of recovery you want to perfom. 


Steps: 


4 Select recovery type 





6. ábra. Bőséges lehetőség adatbázisok visszaállítására 


tényleges megvalósítására pedig részletes se- 
gítséget találunk itt: Backing up and restoring 
databases in SOL Server http://go.microsoft. 
com/fwlink/?LinkID-102629$clcid-0x409. 

Ha most visszatérünk az első kérdésünk 
höz, akkor a hogyanról már lehet némi el 
képzelésünk, nézzük a gyakoriságot és a tar- 
talmat. Ha csak az SOL-t nézzük, akkor 


az adatbázisainkat két kategóriába sorolhat 


MÁRCIUS-ÁPRILIS 


xl 


6 Review recovery selection ge C  Recoverto original instance of SAL Server (Overwrite database) 
The current database files will be ovenwritten during recovery. 
WS8-WSSZTMICROSOFTHÁSSEENWSS. Search WS8-WSS31 on ws8-wss31.ws8demo lo... 


e C Copytotape 
This option copies the database to tape in a DPM library. 


css [TT tres [s 





kat), míg egy termelési 
rendszer mögött állhat 
olyan adatbázis, ahol a 
logokat 15 percenként, 
az adatbázist magát pe- 
dig minden műszak vé- 
gén menteni kell. Hogy 
ne veszítsük el a men- 


tések fonalát a harma- 


. MEG " al--  € Recoverto any SALinstance 
9. Specify recovery options I This option allows you to recoverto any SOL instance on same or altemate server. 
9 Summary S 
[/ C Copyto a network folder 
9 Recovery status 


dik napon, járható út 
lehet, ha készítünk két 
három mentési sablont 
az adatbázisaink men- 
egységes 
módon határozza meg 


tésére, ami 


a teljes, a differenciális 
és logmentések válta- 
kozását kis, közepes és 
nagy terhelésű adatbá- 
zisokra, igazodva az üz- 
leti igényekhez. És ezzel 
el is érkeztünk ahhoz, amit az SOL termino- 
lógia Maintenance Plannek nevez, és hasz- 
nálatáról bőven olvashatunk a fentebb már 
idézett URL-en. 

A rendszeradatbázisokról is essék azért 
még néhány szó, mert teljes szerverkatasztró- 
fa esetén bizony ezekre is szükség van a visz- 
szaálláshoz. A három legfontosabb adatbázis 


a master, a model és az msdb adatbázis. A 


master, mint neve is sugallja, az adatbázisok 
adatbázisa, egyszerűen szólva ez tartalmazza 
az Összes kiszolgálószintű beállítást, mentése 
tehát elengedhetetlen. Ez az adatbázis simple 
recovery modellt követ, és csak teljes men- 
tést támogat. Mindenképpen készítsünk róla 
rendszeres mentéseket, sőt minden alkalom- 
mal mentsük, ha rendszerbeállításokat mó- 
dosítunk, vagy adatbázisaink száma változik. 

Hasonlóképpen járjunk el a model és 
msdb adatbázisokkal: az előbbi tartalmazza 
az alapértelmezett adatbázissémákat (és pél 
dául hotfixek, szervizcsomagok is frissíthe- 
tik), az utóbbi a SOL Server Agent tényke- 
déseinek tárháza (például itt őrződik a men- 
tések története). A recovery modell konfigu- 
rálható, de nem vétünk nagyot, ha a simple 
modellnél maradunk, csak végezzük rendsze- 
resen a mentéseket. 

Nem szükséges mentenünk a Resource és 
tempdb adatbázisokat, ezek nem hordoznak 
pótolhatatlan információkat. Ha létezik, ak- 
kor mindenképpen mentsük a distribution 
adatbázist (menthetjük a többi rendszeradat 
bázissal egy csomagban), de ez az adatbázis 
csak akkor létezik, ha a kiszolgálónk disztri 
bútorként vesz részt egy adatbázis-replikációs 
folyamatban (tehát ne rémüljünk meg, ha 


nem találjuk). 


Mennyiben más 
a SharePoint mentése? 
Sajnos elég sokban, de megfelelő tervszerű- 
séggel a dolog még kezelhető. Amit nagyon 
fontos látnunk, hogy sokkal szerteágazóbb 
információkra van szükségünk, mint egy 
, egyszerű" adatbázismentésnél. Amint az a 
4. ábrán látható, a SharePoint rendszerünk 
ben (legyen az egy egykiszolgálós SharePoint 
Services vagy nagyvállalati MOSS 2007 
farm) az adatokat több helyről kell összegyűj- 
tenünk a mentéshez: a konfigurációs adato- 
kat a ConfigDbB, a feltöltött fájlokat a tarta- 
lom-adatbázisok (ContentDB) tartalmazzák, 
van ezen felül Shared Services Provider (SSP) 
adatbázisunk és keresési adatbázisunk; fon- 
tos, hogy mentsük a SharePoint binárisait 
(fájlszinten), a testre szabott tartalmakat és 
az IIS beállításait - ebben teszi könnyebbé a 
dolgunkat az IIS7, ahol már XML-fájlok tar 
talmazzák a szükséges adatokat. 

Az SOL-adatbázisokkal viszonylag egysze- 
rű dolgunk van, mentsünk minden tarta- 
lom-adatbázist és az SSP-adatbázist. Mentsük 


kv 
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KEK 
5 time recovery points 
E Eg Data on Disk and Tapes that you want. Click recover in the Actions pane to open the Recovery Wizard. 


E] ws8demo local 







s id WS8-DC 4) F-AET Kv Tvtet s 
5B-z All Protected Volumes ő Recovery date: . April 14 2008 
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Recovery time: [1200 PM r] 


Recoverfrom: — Disk S 
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Path: Jan Protected SharePoint Data P Up 





FA wss. content 
ÉÁ SharePoint. AdminContent. 30854050-4d9b-4e5f-abc5-137cibb8c3b8 





kő DPM 2007 Administrator Console Ű 


File Action View Help 


T ő —- tk ; i 
Monitoring 0) Protection [ aes Ala AM zz]) Reporting X Management 


aal 
Protected data: 


Sever [77 Filter J Clear ] 


E-Z Data on Disk and Tapes 
H-T ws8demo local 
6-H WS8-DC 
5 AI Protected Volumes 


Recovery points for: WS8-WSS3TMWMicrosoftttt SSEEXSharePoint. Config. 52ba3e8f-3975-4092-ada3-20c8Sbf77ec38 








e EAT ette e Select the date 
the calendar and the time from the drop down list forthe recovery 
agsi ei Click recoverin the Actions pane to open the Recovery Wizard. 


Recovery date: April 14 2008 


SZ CN Sun Mon Tue Wed Thu Fi Sat . 
5-B WS8-WSS31 "s BE Recovery time: [12-00 Pm s] 
HI.) AI Protected Volumes 6 7 8 9 10 11 12 k v 
E- ÉLŐ AI Protected SharePoint Data 13 [EZI 15 156 17 18 19 Recoverfrom: — Disk szg 
HÁ WS8-WSSZTWicrosoftáttt 20 21 22 23 24 25 26 


(4. AI Protected SOL Instances 27 28 29 30 

















http: fényt san 1/Shared Documents/Forms/ 
http://ws8-wss31/Shared Documents/SMALL IT - Remote Management and Support S 

I http://ws8-wss31/Shared Documents/Core IO Implementer Resource Guide - Standardized to Ra... 

TI http:/fws8-wss31/Shared Documentsfcodes.txt 

I http://fws8-wss31/Shared Documents/COBIT41.pdf 

I http://ws8-wss31/Shared Documents/SMALL IT - Designing the Network.doc 

Hl http://ws8-wss31/Shared Documents/SMALL IT - Introduction to Small IT Solution. doc 

I http://ws8-wss31/Shared Documents/SMALL IT - Test Guide.doc 

(HI http://ws8-wss31/Shared Documents/Core IO Implementer Resource Guide - Standardized to Ra. , . 

I http://fws8-wss31/Shared Documents/PICTO005. JPG 

TI http:/fws8-wss31/Shared Documents/Automating IT Service Management with System Center. v... 


ervices.doc 
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4/10/2008 8:02:54 ... 

4/11/2008 6:00:46 ... Disk 
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4/12/2008 12:02:4... Disk 
4/12/2008 8:01:46 ... Disk 









C Search site 
(ő Search documents 


Name: 


Sharepoint farm name: 


[WS8-WSSZTMicrosofttttSSEEXShareF r] 
IT Search only within a URL 
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Example: http. ÜShaprepointO Tsites vnysíte 











7. ábra. SharePoint-tartalmak helyreállítási lehetőségei 


KR 


— 
0 — 


a konfigurációs adatbázist is, de jó, ha tud- 
juk, hogy ezt csak akkor lehet helyreállításra 
használni, ha teljes kiszolgáló-katasztrófából 
állunk talpra és a kiszolgáló minden para- 
métere pontosan megegyezik az eredetiével 
(név, website-ok konfigurációja, adatbázis- 
instance, adatbázisnév, elérési utak) - be- 
tűről betűre minden. A keresési adatbázis 
közös életet él a hozzátartozó indexfájllal, 
így konzisztens módon csak a SharePoint bel 
ső eszközeivel menthető. Emiatt két megol 
dást választhatunk: vagy a belső eszközökkel 
mentjük, vagy lementjük adatbázisként, és 
helyreállítás esetén számolunk azzal, hogy az 
indexfájl teljes egészében újraépül. 

Fontos, hogy ne csak mentésekkel rendelk 
kezzünk erről a rengetegféle dologról, hanem 
legyen írásos konfigurációs leírásunk is (erő- 
sen javasolt tehát a szigorú változáskezelés), 
mert katasztrófa esetén sok olyan beállítás 
van, amit manuálisan, a dokumentációból 
kell megadnunk, és a helyreállítás sikere mú- 
lik rajta. 

Milyen eszközeink lehetnek a SharePoint 
mentésére? Először is van egy beépített gra- 
fikus eszköz, amelyet a központi adminiszt 
rációs felületen keresztül érhetünk el. Ezzel 
a teljes farmunkat, annak tetszőleges siteját 
és bármelyik adatbázisát menthetjük. Ez az 
eszköz képes konzisztens mentést készíteni 
a keresési adatbázisról is, szinkronizálva azt 
az indexfájllal. Nagy hátránya viszont, hogy 
nem időzíthető, és az adminisztrátor köz- 
vetlen beavatkozását igényli. Az időzítést a 
parancssori stsadm.exe használatával tudjuk 
megvalósítani. Funkcionalitásában ez az esz- 
köz mindent tud, amit a grafikus változat 
(sőt adminisztratív feladatokban többet is), a 
paraméterezése viszont lényegesen nehezebb. 
Mindenképpen szükségünk lesz fájlszintű 
mentésekre is, ezért semmiképpen ne hagy- 
juk ki a 38. oldalon lévő táblázatban találha- 
tó mappákat a rendszeres mentésekből. 

Remélem, mostanra már mindenkiben 


motoszkál a kézenfekvő kérdés. 


Lehetne ezt egyszerűbben? 
A válasz természetesen: igen. A System 
Center Data Protection Manager 2007 az 
alapvető fájlszintű mentéseken túl összetett 
alkalmazásszintű mentéseket is képes készí 
teni Exchange rendszerekről, SOL-kiszolgá- 
lók adatbázisairól, SharePointfarmokról és 


Virtual Server 2005-kiszolgálókról, mindezt 
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pedig egyszerűen kezelhető felületen keresz- 
tül, pilótavizsga nélkül. 

Mielőtt az egyszerűségre mutatnék pél 
dákat, nézzünk egy kicsit mélyebbre a fo- 
lyamatokban, hogy megértsük, mi is zajlik 
a háttérben. Az alkalmazásszintű menté- 
sek minden esetben az árnyékmásolattech- 
nológiára épülnek (Volume Shadow Copy). 
Ahhoz, hogy használni tudjuk a DPM-et 
az SOL- és SharePointkiszolgálók mentésé- 
re, engedélyeznünk kell az SOL VSS Writer 
és SharePoint VSS Writer szolgáltatásokat. 
(Ezek alapértelmezésben kézi indításra van- 
nak állítva, tegyük tehát őket automatiku- 
san indulókká!) A megfelelő mentési szabá- 
lyok (Protection Group) létrehozásakor az 
adatbázisokról egy teljes másolat készül a 
DPM-kiszolgálón és - néhány különleges ese- 


tet kivéve - nem is készül több, hanem egy 


zük, vagy egy másik adatbázis-kiszolgálón 
felcsatoljuk. Ha tudjuk, hogy maximum 512 
árnyékmásolatunk lehet (tehát ennyi diszk- 
blokk-változáscsomagot kezel a rendszer), ak- 
kor az ezekhez tartozó 15 percenkénti log- 
mentéssel akár 344 ezer helyreállítási pontot 
is képezhetünk. (Óránként 4 logmentés x 24 
óra x 7 nap x 512) És ez még csak a diszk alapú 
mentés, ami a közvetlen helyreállítást segíti. 
A DPM kiszolgálóhoz csatlakozó szalagos esz- 
közre az általunk megadott időközönként 
készíthetünk szintetikus mentést (amikor a 
DPM összedolgozza az adatbázisok aktuális 
állapotát egy menthető, konzisztens állapot 
tá), amit aztán hosszabb ideig tárolhatunk, 
letétbe tehetünk, attól függően, hogy mi a 
mentésekre vonatkozó üzleti, jogi elvárás. 
Lássunk akkor néhány képet, hogy ráérez- 
zünk a dolog egyszerűségére! Az első képer- 


nyőn (5. ábra) azt a pilla- 





ves Select Recovery Type 
78 Select the type of recovery you want to perfom. 


Steps: 

4 Review recovery selection 

4 Select recovery type 

9. Specffy recovery options 

4. Summary TT 
9 Recovery status 


What do you want to do with the selected Sharepoint farm? 
(S Recover all Sharepoint content and components 


e € , Copythe Windows SharePoint Services far to tape 








8. ábra. A SharePoint-adatok visszaállítása sem ördöngösség 


fájlszűrő segítségével a DPM innentől kezd- 
ve követi, hogy az adott adatbázisok mely 
diszkblokkokat foglalják el, és ezek közül 
melyik változott. A változásokat egy Express 
Full Backup nevű eljárás keretében veszi át az 
adatbázis-kiszolgálóról és rögzíti a saját diszk- 
jein. (Érdemes tehát az Express Full Backup 
gyakoriságát az adatbázisunk változási gya- 
koriságához igazítani.) Ezenfelül az általunk 
megadott időközönként a tranzakciós logok 
ról is készül egy mentés, itt a legrövidebb 
megadható időpont 15 perc. 

A két metódus együtt alkalmas arra, hogy, 
az adatbázis bármelyik köztes állapotát elő- 


állítsuk, és akár egy megosztáson elhelyez- 
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3] 


Configuration and content databases along with search indices ff any will be recovered to their 


C Copy all Sharepoint content and component files to a network folder 


Memate location E we. ] 


This option copies the Sharepoint farm which contains the selected recovery ítem to a tape. 


— Bak [Nor ] cm [/ Hop ] 


natot láthatjuk, amikor 
valamennyi mentendő 
adatunkról - legyen 
az fájl vagy alkalmazás 
- rendelkezésre áll egy 
konzisztens (értsd: visz- 
szatölthető) állapot. 

A következő képen 
(6. ábra) már egy meg- 
kezdett SOL-adatbázis- 
visszaállítás látható. A 
négy választási lehető- 
ség azt mutatja, milyen 
egyszerűen helyreállít 
hatjuk az adatbázist: az 
eredeti vagy egy alter- 
natív kiszolgálón, vagy 
egy megosztáson, vagy 
akár közvetlenül szalag- 
ra. Az utóbbi opció nem képzavar, remekül 
használható például akkor, ha egy könyvelési 
adatbázist a péntek déli zárást követő állapo- 
tában kell archiválni. (A képen csak szalagos 
egység hiányában szürke az opció.) 

A következő képsor (7 ábra) a SharePoint 
tartalmak helyreállítási lehetőségeit mutatja: 
az első képen még csak azt látjuk, milyen tar- 
talmak állnak rendelkezésre, a másodikon 
már egy konkrét dokumentumot választha- 
tunk ki egy dokumentumtárban, míg a har- 
madik kép azt mutatja be, hogy adott doku- 
mentumra akár rá is kereshetünk, és láthat 
juk, hogy egyáltalán milyen mentett példá- 
nyokkal rendelkezünk belőle. 


ere 


A SharePoint esetén is rendelkezésünkre 
állnak alternatívák a visszatöltésre, noha a 
8. ábra éppen nem az összes lehetőséget mu- 
tatja. Hiányzik róla az alternatív visszatöltés 


egy másik farmba (ami történetesen éppen a 


visszaállítást szolgálja, és mondjuk csak vir- 


A téma irodalma 





a. Backing up and restoring databases in SOL Server 
http://go.microsoft.com/fwlink/?Link1D—10262 
98.cid—0x409 

a SOL Server 2008 Books Online http://msdn2. 
microsoft.com/en-us/library/bb543165(sgl.100). 
aSpx 

a Balássy György blogja: SharePoint backup Power- 
shellel  http://www.msdnkk.hu/Article.aspx?ld- 
—a62397dd-ce5f-dc11-8db3-000/7e9ef0d89 

ma Plan for backup and recovery (Office SharePoint 
Server). (http://go.microsoft.com/fwlink/?Linkld 
—1027998.clcid—0x409) 

ma Administering backup and recovery for Office 
SharePoint Server 2007  (http://go.microsoft. 
com/fwlink/?Link1D—1026278.clcid—0x409) 

a. Usingthe Microsoft SharePointServer2007 backup 
tool (http://searchexchange.techtarget.com/gen- 
eral/0,295582,sid43. gcil275045,00.html) 

a Data protection and recovery for Microsoft Office 
SharePoint Server 2007 in small to medium-sized 
deployments . http://office.microsoft.com/down- 
load/afile.aspx?AssetlD—AM102447701033 

m System Center Data Protection Manager 200/ 
TechCenter . (http://go.microsoft.com/fwlink/?- 
Linkld—1028078.clcid—0x409). 

a How to Recover a Windows SharePoint Services 
Item. (http://go.microsoft.com/fwlink/?Linkld 
—1028158.cid—0x409) 

a How to Recover a Windows SharePoint Services 
Site. (http://go.microsoft.com/fwlink/?Linkld — 
1028268.clcid—0x409) 

a How to Recover a Windows SharePoint Services 
Farm. (http://go.microsoft.com/fwlink/?Linkld 
—1028318.cid—0x409) 





tuális kiszolgálón fut), mert a tesztrendszer 

nem lát másik SharePointkiszolgálót (tehát 

egyetlen másik gépen sem fut SharePoint 

VSS Writer). Ha lenne ilyenünk, akár az 

egész farm tartalmát reprodukálhatnánk a 
másik kiszolgálón. 

Somogyi Csaba 

(Csaba. Somogyi(Omicrosoft.com) 

Microsoft Magyarország 
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TE JÓ ÉG! 


Csak nem egy újabb parancssori környezet? 


CAWINDOWSYsystems2ZwindowspowershellNvI.ON 
powershell.exe -PSConsoleFile , EXProgram Files 
MicrosoftvExchange Servertbinvexshell.pscI" -noexit 
-command ,,. "EXNProgram FilexWMicrosoftvExchange 
Servertbiny Exchange. ps] " 


Nem egy rövid parancs, a lényege egy kon- 
zolfájl és egy szkript közvetlen meghívása a 
PowerShellkörnyezet indítása során. Nézzük 


meg ezt a két állományt! Elsőként a konzolfájlt: 


c ?xml version—" 1.0" encoding—"utf-87?— 
cPSConsoleFile ConsoleSchemaVersion—"1.07— 
cPSVersion— 1.0-G/PSVersion— 
cPSSnaplnsz 
cPSSnapln Name—" Microsoft. Exchange. 
Management. PowerShell.Admin" /5 
c/PSSnaplnsz 
c/PSConsoleFilez 


ok informatikus első találkozása a PowerShellklel az Exchange Server 2007 kapcsán 
történt meg, nálam is ez a helyzet. Hiszen míg a Windows XP, Windows Server 2003, 
Windows Vista, sőt még a Windows Server 2008 esetében is ez a komponens opcionális, 
nem kötelező alkalmazni, addig az Exchange Server 2007 üzemeltetése során nem lehet meg- 
kerülni a használatát. 
Ennek a cikknek nem az a célja, hogy elmélyedjen az Exchange Server 2007 részleteiben, 
így azok is bátran elolvashatják, akik azt nem ismerik. A célom inkább a PowerShell bővíté- 
si lehetőségeinek bemutatása az Exchange példáján keresztül, illetve azoknak az eltéréseknek, Itt töltődik be az Exchange Server rendszer- 


újdonságoknak a kiemelése az , alap" kezeléssel kapcsolatos cmdleteket tartalma- 















PowerShellhez képest, amelyek - vé- zó beépülő modul, vagy más néven snapin. 





Adminisírator 


JÚ Manage Your Server 
Gúg Administrative Tools ; 


real 
(ev Windows Explorer 
2. Windows Catalog 


[dd Notepad 
9 Windows Update 


ti Windows Powet Aa Áccessories 

FA Sstartup 
mi Command Prom 83 Internet Explorer 
6 Outlook Express 
4— Remote ássistance 
(FA Administrative Tools 








leményem szerint - képesek előreve- Nézzük a szkriptet (csak a fontosabb részeit): 


gő My Computer 
íg Control Panel 


títeni a PowerShell továbbfejlesztésé- , 


z£ Copyright (c) Microsoft Corporation. All rights reserved. 


nek irányait is. 





Első ránézésre 
Ha az Exchange Server 2007 prog- 


4 PRONPT EFE TETTTTTT TIT TT 
7777 Powershell can support very rich prompts, this 

77 simple one prints the current working directory and 
7777 updates the console window title to show the 

77 7 machine name and directory. 











ramcsoportban meglátjuk az Ex 


d €3 Exchange Management Console 
; ee Exchange Management Shell 

k B Exchange Server Help 
mA Microsoft Windovis Mobile 5.0 MSFP Emulator Images b 
ds SU Aa Windows Support Tools ; 


Log Off Hi Shut Down 


(FT. Windows PowerShell 1.0 
(FA Device Emulator Preview 


change Management Shellt, az elne- 


vezés alapján megijedhetünk, hogy 












ez egy újabb parancssori környezet, function prompt 





de szerencsére nem erről van szó, ez 


is a PowerShell. 


1. ábra. Az Exchange Management Shell valójában egy testre 
szabott PowerShell 


Ha rákattintunk az ikonra, akkor 
egy PowerShelbablakot kapunk, de nem teljesen ugyanolyat, mint az , igazi" PowerShell eseté- 
ben. És hogy milyen ez az ablak? 

Ez az ablak alaphelyzetben kicsit , csúnya", fekete a háttere, ellentétben a szép mélykék 
, alap" PowerShelllel, nincs bekapcsolva a (?uick Edit üzemmód, pici az ablak puffermérete, 
így csak kevés sort őriz meg. De természetesen ezeket a hiányosságokat nyugodtan orvosolhat 
juk az ablak tulajdonságainak átállításával. 

A másik különbség az , igazi" PowerShelltablakhoz képest, hogy az ablak fejlécében az ab- 
lakot futtató gép neve és az Active Directory valamely ágának megnevezése látható, valamint 
alaphelyzetben be van töltve az Exchange snapiin, amit le is kérdezhetünk (a nem erre vonat 


kozó részeket helytakarékossági okokból kivágtam, és csak pontozással jelöltem): 


PS] CAs Get-PSSnapin 


Name. : Microsoft.Exchange. Management. PowerShell.Admin 
Description : Admin Tasks for the Exchange Server PSVersion. : 1.0 


Minden más tekintetben ez egy , normális" PowerShellbablak, tehát mindaz alkalmazható, 
használható benne, amit a PowerShellben amúgy megszoktunk. Minek köszönhetők ezek a 
változások az alap PowerShelkkonzolhoz képest? Ha megnézzük a fenti parancsikon mögötti 


parancssort, akkor ezt láthatjuk: 


40 


$cwd — (get-location).Path 
$scope — , View Entire Forest" 
if (ISAdminSessionADSeettings.ViewEntireForest) 


$scope — SAdminSessionADSettings.DefaultScope 


hi 

S host. UL.RawUI.WindowTitle — , Machine: ,, -- 
$(hostname) -- ,, ! Scope: ,, -- $scope 

$host.ULWrite(, Yellow", $host.UI.RawUl. 
BackGroundColor, , PS") 

, Swd— 





7 FUNCIIONS ES ESETELETEHTTR 
747 returns all defined functions 


77 7 only returns exchange commands function get- 
excommand 


3. 
if (Sargs[0] -eg $null) 
1 
get-command -pssnapin Microsoft.Exchange? 
else 


1 
get-command Sargs[0] ] where £ 5. .psSnapin 
-ilike "Microsoft.Exchange"" ) 
h 
) 


Microsoft TechNet 
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Ebben a szkriptben láthatjuk néhány vál 
tozó definiálását, a prompt és az ablak fejlé- 
cének beállítását, néhány függvény definiálá- 
sát. Érdekes módon az Exchange snap-iin ál 
tal definiált cmdletek kilistázását végző get-ex- 
command nem cmdlet, hanem függvény! Ebből 
következően esetében például nem működik 
a tab kiegészítés, és a get-help-pel sem lehet se- 


gítséget kérni a használatával kapcsolatban. 


Az Exchange-cmdletek feltérképezése 
Nem egyszetű az ilyen Exchange snapiin által 
biztosított új cmdletek áttekintése. Elsőként 


nézzük meg, hány új cmdletünk van: 


[PST CAS (get-command -PSSnapin ,, Microsoft.Exchange. 
Management.PowerShell.Admin" 

).Count 

394 


Nem kevés, 394 darab új cmdlet, az alap 
129-cel szemben! Hogyan lehet ezeket átte- 
kinteni? Szerencsére kapunk segítséget egy- 
részt a get-command, másrészt a get-help cmdlettől 
is. A get-command esetében használhatjuk a verb 


és a N0Un paramétert: 
(PSI CAS get-command -noun mailbox 


Definition 


CommandType . Name 


Cmdlet 


Cmilet Disable-Moilbox.. Disable-Moilbox [-ldentityl] 


[PSI GAS get-command -verb export 


CommandType Name Definition 


Cmdlet Export-ActiveSyncLog . Export-ActiveSynclLog - 
Filena... 

Cmdlet Export-Alias Export-Alias [-Path] 
SIN. 


Ha még ez sem lenne kellő segítség, akkor 
a get-help esetében használhatjuk a role, com- 
ponent és functionality paramétereket. Például a 
mailbox szerepű kiszolgálókon használható, 
szervezetszintű jogosultságok beállításával 


kapcsolatos cmdletek listáját az alábbi mó- 


don kérhetjük le: 


(PS CAS-get-help -role "mail? -component "permission" - 
functionality global 


Name Category . Synopsis 

Get-ADPermission Cmdlet Use the Get-ADPermissi... 
Add-ADPermission Cmdlet Use the Add-ADPermissi... 
Remove-ADPermission  Cmdlet Use the Remove-ADPermi... 
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Felhasználó- és csoportkezelés 
Az Exchangerendszergazda tevékenységei 
közé a felhasználók és csoportok kezelése 
is beletartozik, így az Exchange PowerShell 
snap-in tartalmaz ezzel kapcsolatos cmdlete- 
ket is. Az alap PowerShellben az [ADSI] típus- 
jelölővel lehet hivatkozni AD-objektumok- 
ra, az Exchange-környezetben még egysze- 
rűbb a helyzet. Nem teljes értékű ugyan 
az AD felhasználómenedzsmentre. szolgáló 
parancskészlete, hanem kifejezetten csak az 
Exchange Server rendszergazdáinak igényei 
re szabott, de azért így is sokat profitálhatunk 
belőle. Nézzük például a get-user cmdletet: 


IPSIGAS-get-user brian 
Name Recipientlype 
Brian Cox UserMailbox 


Nézzük meg kicsit részletesebben Briant: 


[PSTCASget-user brian ] fi 


IsSecurityPrincipal.. : True 
SamAccountName . : Brian 


Sid : §-1-5-21-150787130-2833054149- 
3003060369-1132 

SidHistory síp 

UserPrincipalName. : Brian-oAdatum.com 

Don lyNAine : Brian Cox 

Title 


DistingvishedName : CN—Brian Cox 0U—Legal DC—Adatum, 
D(—com 


identity : Adatum.com/Legal/Brian Cox 

Guid : debelf52-f0ea-4da0-b049- 
0122c2d45db2 

ObjectCategory . : Adatum.com/Configuration/Schema/ 
Person 

ObjectClass : top, person, organizationalPerson, usert 
WhenChanged  : 2007.01.03. 19:50:42 

WhenCreated : 2007.01.03. 19:17:26 


Nagyon sok tulajdonság lekérdezhető a fel 
használói fiókokkal kapcsolatban. A további, 
Exchange-dzsel kapcsolatos attribútumot a 


get-mailbox cmdlettel lehet lekérdezni. 


Get és Set 


A fenti táblázatban a Iitle (beosztás) paramé- 


ter üres. Próbáljuk ezt feltölteni: 


IPSTCAs$u — Get-User brian 
[PS As $u.title — "Portás" 
(PST CAsdu.title 

Portás 


Látszólag sikerült beállítani Brian beosz- 


tását, mint ahogy az utolsó, ellenőrző sorban 
látható, de ha az Active Directory Users and 
Computer eszközzel megnézzük Briant, ak 


kor nem látjuk ezt a paramétert kitöltve: 


d E tanár idáá-0 Í ?1XxI 


MemberOf — ]  Diakim — ] Environment — ] 0 Sessions ] 
Remote control ] Terminal Services Profile ] coMr ] 
Organization 


General ] Address ] Account ] Profile ] Telephones 


Title: [I 
Department: [Legal 


Change... j Properties j Clear ! 


Direct reports: 








red [ee] 


2. ábra. Nem történt meg Brian adatainak módosítása 








Mi: történt akkor? Az AD-vel kapcsolatos 
Get-... kezdetű cmdletek nem direktben dol 
goznak a címtárban, hanem a címtárinfor- 
mációkat betöltik a memóriába. Így az érték 
adás utasításom is a memóriában hajtódott 
végre és nem ténylegesen a felhasználói fió- 
kon. Ezért van az AD-vel kapcsolatos dGet-... 
cmdleteknek egy Set-... párjuk is, mert ez már 
ténylegesen beírja az értékeket a címtár adat 
bázisába. Nézzük meg, hogyan lehet ténylege- 


sen címtárparamétert megváltoztatni: 


[PSI CAS Set-User brian Title , Portás" 
(PST CAS Get-User brian ] f Name, Title 


Name : Brian Cox 
Title : Portás 


Vigyázni kell, hogy nem teljesen szimmet 
rikusak a Get-... és a Set-... cmdletpárok. Jól mu- 
tatja ezt a csoportok kezelését végző Get-Group 
és a Set-Group páros: 


[PS CNSget-group sales ] fi 


SamAccountName  : Sales 


Members : (Jeff Hay, Don Hall, Judy Lewj 


A fenti példából látszik, hogy a csoport 
tagjai (Members) lekérdezhetők a get-group-pal. 
Nézzük meg a Set-Group szintaxisát: 
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Set-Group 
-Identity cGroupldParameter— 

[-Confirm [ CSwitchParameter— 1] 
[-DisplayName cString- ] 

[-DomainController cFgdn-] 
[-IgnoreDefaultScope c SwitchParameter— ] 
[-ManagedBy —GeneralRecipientldParameter— ] 
[-Name cStringc] 

[-Notes cString] 

[-PhoneticDisplayName cString-] 
[-SimpleDisplayName c String2] 

[-Whatlf [ cSwitchParameter— ]] 
[-WindowsEmailAddress cSmtpAddressz] 
[CCommonParameters2 ] 


Itt viszont nem látunk a Members attri 
Mindez 
azt bizonyítja, hogy az Exchange-cmdletek 


bútumra vonatkozó paramétert. 


nem próbálják meg magukra vállalni a teljes 
Active Directory kezelését, arra vagy az [ADSI] 
típushivatkozást, vagy külső gyártó snap-in- 


jét használhatjuk. 


; 
Uj paraméterfajta: identity 

Az előző példákban elég nagyvonalúan hivat 
koztam Brianre, semmi distinguished name, 
semmi canonical name nem szerepelt a hi- 
vatkozásban, holott például az [ADSI] haszná- 
latánál teljes, pontos distinguished name 
kitöltésére van szükség. Mi teszi lehetővé ezt 
az egyszerű, kényelmes használatot? Nézzük 


meg a gef-user súgóját: 


IPSIT GAS get-help Get-User 


SYNTAX 

get-User [-Identity cUserldParameter— ] [-Credential 
cPS(redential-] [-DomainController cFgdn-] [-Ignore 
DefaultScope cSwitchParameter— ] [-OrganizationalUnit c0 
rganizationalUnitldParameter— ] [-ReadFromDomainController 
cSwitchParameter— ] [-RecipientlypeDetails cRecipientlype 
Details[15] [-ResultSize cUnlimited—] [-Sortby cString2 ] 
[CCommonParameters2 ] 


get-User [-Credential cPSCredential— ] [-DomainController 
cEgdno] [-Filter cString2] [-lgnoreDefaultScope c Switch 
Parameter— ] [-OrganizationalUnit a Organizational 
UnitldParameter— ] [-ReadFromDomainController cSwitch 
Parameter— ] [-RecipientlypeDetails cRecipientlype 
Details[15] [-ResultSize cUnlimited—] [-Sortby cString5 ] 
[-CommonParameters2 ] 


get-User [-Anr cString2 ] [-Credential cPSCredential— ] 
[-DomainController cFgdn-] [-IlgnoreDefaultScope c Switch 
Parameter— ] [-OrganizationalUnit a Organizational 
UnitldParameter— ] [-ReadFromDomainController cSwitch 
Parameter— ] [-RecipientlypeDetails cRecipientlype 
Details[15] [-ResultSize cUnlimited—] [-Sortby cString5 ] 
[CCommonParameters2 ] 


PARAMETERS 
-Anr CStringz 


1 


The Anr parameter indicates that the argument will be 
resolved using ambigvous name resolution (ANR). 


-Identity CUserldParameter— 
The Identity parameter takes one of the following values: 
" GUID 
" Distinguished name (DN) 
" Domain ccount 
" User principal name (UPN) 
" Legacy Exchange DN 
" Simple Mail Transfer Protocol (SMTP) address 
" Alias 


Látszik, hogy a többfajta szintaxisa alap- 
ján az első paramétert vagy ANR (Ambiguous 
Name Resolution) névfeloldásra, vagy - eh- 
hez nagyon hasonló - lIdentity típusú névfel 
oldásra használja. Az lIdentity paraméter ma- 
gyarázatát a fenti help-részletben láthatjuk is. 
Azt, hogy most melyiket használta, nem tud- 


juk, hiszen mindkettő jó eredményre vezet: 


IPSIT AS Get-User -anr brian 


Name Recipientlype 


Brian Cox UserMailbox 


[PPSJ CAS Get-User -identity brian 


Name Recipientlype 


Brian Cox UserMailbox 


Mi ebből a tanulság? Hogy az Exchange- 
cmdletek kialakításánál törekedtek arra a 
fejlesztők, hogy a lehető legegyszerűbben le- 
hessen hivatkozni az AD-objektumokra. Elég 
hamar elmenne a kedvünk a szkriptek írásá- 
tól, ha minden esetben csak a teljes distin- 
guished name kiírásával lehetne hivatkozni 
az AD-objektumokra, így azonban az lIdentity 
(és a felhasználókkal kapcsolatban az ANR) pa- 
raméterrel elég csak olyan mértékig utalni a 
keresett objektumokra, amikor már egyértel 
mű a cmdlet számára, hogy kire vagy mire 
gondoltunk. 

Például a get-MailboxDatabase cmdletnél az 
Identity paraméter a következőket jelentheti: 

-Identity cDatabaseldParameter— 

The Identity parameter specifies a mailbox database. You 
can use the following values: 

" GUID 

" Distinguished name (DN) 

" Serventstorage groupidatabase name 

" Servenvdatabase name 

" Storage groupnametdatabase name 

Ifyou do not specify the server name, the cmdlet will 
search for databases on the local server. Ifyov have multiple 


databases with the same name, the cmdlet will retrieve all data- 
bases with the same name in the specified scope. 


clael] x 


Azaz, a megjegyzés alapján, akár elég csak 
az adatbázis nevét megadni, ha az egyértel 
mű, és nem kell az adatbázis distinguished 
nevét használni, ami elég elrettentő lenne. 
Az alábbi példában lekérdezem ezt, a válasz 


három és fél sor! 


[PSI CAS (Get-MailboxDatabase ,,syd-del mailbox database"). 
DistingvishedNameCN —Mailbox Database ,((N—First Storage 
Group, CN—InformationStore CN—SYD-DCI,(N—Servers, CN 
—Exchange Administrative Group (FYDIBOHF23SPDLT),CN 

— Administrative Groups (N—Adatum Organization, CN 
—Microsoft Exchange (N— Services CN— Configuration, DC 

— datum DC— com 


Filter paraméter 

A másik hatékonyságnövelő paraméter szá- 
mos Exchange-cmdletnél a Filter paraméter. 
Nézzük meg, hogy PowerShellismereteink 
alapján hogyan keresnénk meg az összes 
olyan felhasználónkat, akinek ki van töltve a 


beosztás tulajdonsága: 


[PS] CAsget-user [ Where-Object ($ Title -ne ,") 


Name Recipientlype 
Brian Cox UserMailbox 
Kim Akers UserMailbox 


Hogyan hajtódik ez végre? A get-user cmdlet 
tel az összes felhasználói objektumot kigyűjt 
jük, és maga a PowerShellkörnyezet a kliens 
oldalon válogatja ki közülük azokat, amelyek- 
nél a litle paraméter nem üres sztring. Ez egy 
tízezres felhasználószámnál komoly feldol 
gozási munkát és memóriát igényel, és nagy 
hálózati forgalmat generál. Ezért kidolgoztak 
egy kiszolgálóoldali feldolgozási lehetőséget 
is az ilyen jellegű AD-cmdleteknél a Filter pa- 
raméter alkalmazásával. 

Itt úgynevezett OPATH filtereket, , pre- 
scanned filter"-eket használhatunk, ami a 


szerveroldalon hajtódik végre: 


PPSI GAS Get-User -filter (Title -ne ,") 


Name Recipientlype 
Brian Cox UserMailbox 
Kim Akers .  UserMailbox 


Ennek köszönhetően jóval hatékonyabbá 
és gyorsabbá tehető a feldolgozás. A Filter para- 
méterben is használhatjuk a PowerShellben 
megszokott összehasonlító operátorokat és 
az ott alkalmazott szintaxist, azonban nem 


az ,igazi" attribútumnevekkel hivatkozunk, 
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hanem a speciális OPATH-attribútumne- 
vekkel. 


Miért kell megtanulni 
rPowerShellül"? 

Végezetül azt emelném ki, hogy miért 
kell egy rendszergazdának megtanulnia a 
PowerShellt. Az Exchange Server 2007 példá- 
ja megmutatja számunkra, hogy a jövőben a 
Microsoft kiszolgálószoftverek grafikus keze- 
lői felületére nem lesz minden kivezetve, csak 
a leggyakoribb feladatok elvégzéséhez szük- 
séges elemek. Viszont a .Net Frameworkben 
minden felügyeleti objektum benne lesz, és 
PowerShell 


cmdletek rendelkezésre fognak állni. 


konfigurálásukhoz szükséges 

Példaként nézzük meg, hogy melyek azok 
a legfontosabb tevékenységek, amelyeket 
nem lehet a grafikus felületen, az Exchange 


Management Console-on végrehajtani. 


Postafiók-exportálás 
A postafiókokkal kapcsolatos egyik leg- 
tevékenység 


mélyrehatóbb rendszergazdai 


azok tartalmának kiexportálása. A koráb- 


található karaktersorozatra, kizárhatunk bi 
zonyos mappákat a postafiókon belül, kitö- 
rölhetjük az exportált tartalmat az eredeti 
postaládából. Mindezt egy szkriptbe ágyazva 
elég összetett feladatokat is elvégezhetünk. 
Az alábbi kétsoros PowerShellkifejezéssel pél 
dául a ,Jogi osztály" összes munkatársának 
olyan üzeneteit exportálom az Ellenőr Elemér 
postafiókjának , Export" nevű mappájába, 


amely üzenetek tartalmazzák a ,titkos" szót: 


[PSTCA5$dn— (get-group , Jogi osztály"). DistingvishedName 
[PST CAS Get-Mailbox -filter (MemberOfGroup -eg $dn? ] 
Export-Mailbox -AllContentKeywords , titkos" -TargetMailbox 
Administrator -TargetFolder Export 


Erőforrás-naptárak kezelése 

Újdonság az Exchange Server 2007-ben a ki 
fejezetten erőforrás (például: tárgyaló, pro- 
jektor stb.) céljaira létrehozott levelesládák 
létrehozásának lehetősége. Ezt megtehetjük 
a grafikus felületen, de az erőforrás naptár- 
jának tulajdonságait már csak PowerShelL 
cmdletekkel állíthatjuk be. Nézzünk erre 
is egy példát! Létrehoztam egy tárgyalót, 
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Az Exchange Server 2007 számtalan eszközzel felügyelhető 


bi Exchange-verzióknál erre egy grafikus 
eszköz, az ExMerge állt rendelkezésre. Az 
Exchange Server 2007-ben ez az eszköz nem 
támogatott, helyette egy PowerShelblcmdlet, 
az Export-Mailbox áll rendelkezésünkre, amely 
sokkal több lehetőséget biztosít számunkra. 

Például az export során szűrhetünk a tárgy- 
sorban, üzenettörzsben vagy a csatolmányban 


található szóra, címzettben vagy feladóban 


MÁRCIUS-ÁPRILIS 





és beállítottam a Titkárnőt teljes jogkörrel. 
Ezenkívül azt szeretném, hogy a Főnök és a 
Titkárnő bármikor szervezhessen találkozót, 
a Beosztott pedig csak igényelhesse a tárgya- 
lót, de azt jóvá kell hagynia a Titkárnőnek. 
Ezenkívül a Főnök bármikor, akár munka- 
időn túl is lefoglalhassa a tárgyalót, de a 
Beosztott csak munkaidőben. Továbbá szeret 


ném, ha a tárgyalónál látnák a munkatársak, 


hogy 10 fő fér el benne, és hogy hűtőszekrény 


és projektor is tartozik a felszereltséghez: 


(PSI GAS Set-MailboxCalendarSettings tárgyaló 
-AutomateProcessing autoaccept 

(PSI GAS Set-MailboxCalendarSettings tárgyaló 
-ResourceDelegates Titkárnő 

(PSI GAS Set-MailboxCalendarSettings tárgyaló 
-RegvestOutOfPolicy Főnök -Regvest 

InPolicy Beosztott -AllBooklnPolicy $false 

[PSI CASSet-ResourceConfig -ResourcePropertySchema room/ 
projektor, room/hűtőszekrény 

(PS CAS Set-Mailbox Tárgyaló -ResourceCapacity 10 - 
ResourceCustom projektor, hűtőszekrény 


Az első három sort csak a jobb olvashatóság 
miatt írtam külön. A grafikus felületen csak az 
utolsó sornak megfelelő beállítást lehetett vol 
na elvégezni, de azt meg kell előznie a negye- 
dik kifejezésnek. Ebben a példában igazából 
nem volt PowerShell szinten nagy trükk, de ha 
bonyolultabb lenne azoknak a személyeknek a 
köre, akik delegáltjai vagy igénylői az erőforrá- 
soknak, ráadásul nem is egy, hanem több erő- 
forrásra akarjuk ezeket beállítani, akkor nem 


árt megint csak PowerShellül tudni. 


Standby Continuous Replication 

Az egyik legösszetettebb és legfelelősségtelje- 
sebb rendszergazdai tevékenység a rendszer 
meghibásodásakor a minél gyorsabb és minél 
kevesebb adatveszteség nélküli helyreállítás. 
Az Exchange Server 2007 erre a célra az SP! ja- 
vítócsomaggal egy nagyon praktikus, új lehető- 
séget kínál, a Standby Continuous Replicationt, 
amelynek során egy , tartalék" kiszolgálóra tölt 
jük át folyamatosan az adatbázisunk tranzakci- 
ós naplóit, és ezen a tartalék kiszolgálón épít 
jük folyamatosan az , árnyék" adatbázist. Ha 
az elsődleges kiszolgálónk tönkremegy, akkor 
ezen a tartalék kiszolgálón be tudjuk üzemelni 
az árnyékpéldányt. Ez nem fürtözési technoló- 
gia, azaz nem automatikus az átállás, előnye 
azonban, hogy sokkal egyszerűbb a beállítása, 
és nem igényel speciális hardvert. Az egész 
módszert azonban csak PowerShellkcmdletek 
segítségével tudjuk elindítani, a grafikus felü- 
leten nem is látszik ebből semmi. 

Nézzük tömören a lépéseket. A syd-dcl 
mester gépen, az scr-sg tároló csoport SCT- 
db adatbázisából szeretnék egy másolati pél 
dányt a syd-ex2 kiszolgálóra. Az SCR repliká- 
ció elindításához, a forrásgépen, a , mester" 


példánynál kiadjuk a következő parancsot: 


[PS] CAS-Enable-StorageGroupCopy syd-delVscr-sg 
-Standby Machine syd-ex2 -ReplayLagTime 0.0-1:0 
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A legvégén található idő paraméter a tranz- 
akciós logfájlok visszajátszásának késleltetését 
állítottam be 1 percre, mert az alapbeállítás 1 
nap, ami tesztelés esetében kicsit hosszú. 

Ha jön a meghibásodás, és esetleg nem 
kapcsolódott volna le a meghibásodott adat 
bázis, akkor állítsuk le: 


[PS CAS Dismount-Database syd-delVscr-db 


Confirm 

Are you sure you want to perform this action? 

Dismounting database ,,syd-delvscr-db". 

(YI Yes [AT Yes to AII (NI No (LI No to AI [S] Suspend [9] 

Help 

(default is , Y"):y 

Ezután következik az SCR másolati gép- 

re az adatbázis helyreállítása, azaz a másolati 


példány , beélesítése": 


[PS CAS Restore-StorageGroupCopy syd-delVscr-sg 
-StandbyMachine syd-ex2 


Miután az SCR másolati gépen nincs defi- 
niálva ennek az adatbázisnak a helye , hivata- 
losan", az így épített adatbázis azonnal nem 
használható, így az SCR másolati példányt 


egy nem használt, , igazi" mailbox-adatbázis 


helyett kell bekötni: 





[PSI CAS-Move-StorageGroupPath , syd-ex2N First 
Storage Group" -SystemFolderPath cAscrdb 
-LogFolderPath CXscrdb -ConfigurationOnly 


IPST CAS Move-DatabasePath , syd-ex2Mailbox Database" 
-EdbFilePath CYscrdbiscr-db.edb -ConfigurationOnly 


Ezután a helyreállítást engedélyezni kell, 
hiszen az eredeti adatbázis SCR-árnyékra cse- 


rélését a rendszer helyreállításként értelmezi: 


IPSI CASSet-MailboxDatabase ,,syd-ex2xWMailbox 
Database" -AllowFileRestore $true 


Szükségessé válhat itt az SCR-célgépen az 
adatbázis javítása, mert a tranzakciós napló- 
fájlok nevének más lehet az előtagja a két 
SCR-gép között. 

Jelen esetben a mestergépen E0O2 az előtag, 


az SCR-másolaton meg E00: 


CYAscrdb— esevtil -r £02 


Extensible Storage Engine Utilities for Microsoft(R) 
Exchange Server 
Version 08.01 
Copyright (C) Microsoft Corporation. AlI Rights Reserved. 
Initiating RECOVERY mode... 
Logfile base name: £02 
Log files: current directory 


Izgatott 
/ 


Can you spot talent? Express yourself. 





System files: current directory 
Performing soft recovery... 
Restore Status (49 complete) 


0 10.20 30 40 50 60 /0 80 90 pa 


Operation completed successfully in 33.929 seconds. 


Ezután az adatbázist már elindíthatjuk: 
IPST CAS:Mount-Database ,,syd-ex2AMailbox Database" 


Most már csak a felhasználók mailboxatt 


ribútumát kell átirányítani az új adatbázisra: 


IPST CAS Get-Mailbox -database syd-delVscr- 

db [where ($ . .ObjectClass -NotMatch " 
(SystemAttendantMailbox ] ExXOleDbSystemMailbox)" 
Move-Mailbox -TargetDatabase , syd-ex2AMailbox 
Database" -ConfigurationOnly 





Ezzel készen is vagyunk. Ezt az utolsó ki 
fejezést az teszi bonyolulttá, hogy a rendszer 
által használt speciális mailboxokat nem sza- 
bad átirányítani. 

Soós Tibor 
(soostigjb.hu) 
MCT, IÓSOFT — John Bryce Oktatóközpont 
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A Microsoft termékei, technológiái és szolgál- 
tatásai arra születtek, hogy valóra váltsák 
ügyfeleink igényeit a világ minden táján. 


Nyitott technológiai pozícióink a karrier és 
tanulási lehetőségek széles skáláját nyújtják 
tapasztalt és tanulni vágyó informatikai 
szakembereknek egyaránt: 
Architect -— Core Infrastructure 
Architect — Business Productivity 
Engagement Manager 
Project Manager 
Solution Sales Professional — SOA 
IPTV Premier Field Engineer 
Consultant - Application Development 
Consultant - Infrastructure 
Partner Technical Consultant 


A pozíciókról bővebben karrieroldalunkon 
olvashatsz: www.microsoft.com/hunzkarrier. 
Ha felkeltette érdeklődésed a Microsoft, kérjük, 
hogy jelentkezz az allasoamicrosoft.com 
címen egy önéletrajz küldésével! 





Keressük azokat az informatikai szakembereket, 
akik tapasztalataikkal, és elhivatottságukkal 
segítik a Microsoft ügyfeleit informatikai 
megoldások kialakításában. 


A Microsoftnál minden lehetőség adott, hogy 
önmagad légy és megvalósítsd ötleteidet! 


Microsoft 


Neked lehetőség. Nekünk kihívás. 
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A Fujitsu Siemens Computers áttörő IT infrastruktúra-megoldásai éppoly rugalmasan alkalmazkodnak 
a váratlan helyzetekhez, mint On. 


A Fujitsu Siemens Computers FlexFrame" Infrastructure rendszere tökéletesen illeszkedik az adatközponti 
környezetekbe. Az egyes szoftverfejlesztők által támogatott rugalmas IT-platform dinamikusan rendeli hozzá 

a szervererőforrásokat az egyes alkalmazásokhoz. A nagy teljesítményű, négymagos Intel$ Xeon? processzorral 
ellátott PRIMERGY RX300 szerverekre épülő megoldás minden speciális igényt kielégít az alkalmazások támo- 
gatása terén. Hiba esetén az érintett alkalmazások dinamikus áthelyezésével tartja fenn a zavartalan működést. 
Miért is jó ez Önnek? Mert a kivételes rugalmasságnak köszönhetően végre minden energiájával az üzleti műkö- 
désre koncentrálhat. És ez csak egy a Fujitsu Siemens Computers Dinamikus Adatközponthoz készült innovatív 
megoldásai közül! 


Xeon 
inside" 


Ouad-core. 
Unmatched. 


www.fujitsu-siemens.hu 


Az alábbiak az Intel Corporation Egyesült államokban vagy más országokban használt védjegyei: Celeron, Celeron Inside, Centrino, Centrino Logo, Core Inside, Intel, 
Intel Logo, Intel Core, Intel Inside, Intel Inside Logo, Intel Viiv, Intel vPro, Itanium, Itanium Inside, Pentium, Pentium Inside, Xeon, és Xeon Inside. 
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A DISTRIBUTED 


FILE SYSTEM 





Az adatok elhelyezésének és szervezésének számtalan módja 


van. Tárolhatjuk őket adatbázisban, floppylemezen, pendrive-on, 


publikálhatjuk webes tartalomként, vagy elmenthetjük 


szalagra. Most mégis maradjunk az irodai környezetben talán 


legnagyományosabbnak mondható módszernél: helyezzük el 


adatainkat a fájlszerveren, és tegyük ott elérhetővé a felhasználók 


számára. 


oltaképpen persze nem túl izgalmas a történet. A hálózati felhasználó kitallózza magá- 
vV nak a megfelelő kiszolgálót, rálel a szerencsés esetben beszédes nevű megosztásra, ott a 

mögöttes könyvtárstruktúrában biztos kézzel kattintgatva eljut a tizenhatodik alkönyv- 
tárba - és a kívánt fájl már meg is van. Nincs itt semmi hiba, a rendszer gazdája időről időre 
elmagyarázza az újonnan belépő alkalmazottaknak, hogy mit hol találnak. Igen ám! De a cég 
növekszik, egyre több a felhasználó, egyre több a napi használatú adat, és ha lehunyjuk a sze- 
münket egy-két évre, egy olyan infrastruktúrát látunk ébredéskor, amelyben több tucat szerver 
több telephelyen tárolja felhasználók százainak vagy akár ezreinek adatait. 

Ebbe a környezetbe képzeljük bele Béla bácsit és Juliska nénit mint a rendszerrel épp most 
ismerkedő felhasználókat. Rendszergazda jön, nagy levegőt vesz, és elkezdi hosszasan sorol 
ni, hogy az adott munkakörhöz tartozó állományok mely szerverEK melyik megosztásA I BAN, 
mely alkönyvtárAKban találhatók. Míg Béla 





bácsi pislogva memorizál, és csak három — JELZETT zi 


perc múlva adja fel, addig Juliska néni már 


az első perc után könnyes szemmel papír- TéT 


Jasdtetők s ÁG 

ÖN VESSE [E 9 EATER et vesd [Best (test hi 

JESSSSZERRR [EI III LEELEELL 
[ese avaleadi 21 


zsebkendő után kutat... Nem beszélve arról, 
hogy egy olyan telephelyen fognak dolgozni, 
amelyik az adatközponttal csak egy jóféle 512 





kbit/másodperces kapcsolattal bír. Míg egy- 





egy fájl megnyitása közben Béla bácsi átfut 








hatja a teljes sportrovatot, addig Juliska néni Tuesday 7ODAM 530PM 105hors  2Mbp 
Tuesday 7:00 PM 12:00 AM 5 hours 4 Mbps 
a társkeresőt olvashatja el. Főleg, ha megta- ke. ám B. at 
Ka gi ő si ; Thursd; 7:00 AM 5:30 PM 10.5 hi 2 Mbi 
lálják a szükséges fájlt. Feltéve, hogy akarnak Thursday ZODPM ——D12O0AM —— 5ham  4lbos cl 
ilyen környezetben dolgozni egyáltalán. Fdfln f/ Bé] mas] 
cDetais —Cencd 


Itt kap szerepet az a szolgáltatás, amelyet 


névről ismerhetünk már a Windows NTs  ]. ábra. A DFS replikációjának időzítése 


kö 


korszak óta, bár ott addendumként illeszt 
hettük a rendszerhez, a Windows 2000-ben 
már a telepítőcsomag része: a DFS, azaz a 
Distributed File System. Ezt a DFS-t újítot 
ták meg, egészítették ki és tették nagyon sok 
meglévő problémára megoldásként felhasz- 
nálhatóvá a Windows Server 2008-ban. Mit 
tudott és mit tud most a DF$S? 


DFS az előző Windows-verziókban 

Standalone DFS. Noha ez az írás nem a 
múltba igyekszik tekinteni, nézzük meg, hogy 
milyen környezetet alakíthattunk ki DES-sel 
régebben. A probléma adott: sok szerveren, 
sok megosztásban, bonyolult könyvtárstruk- 
túrában sokak adatai laknak, valószínűleg 
a legjobban csoportosítva. A legjobban, de 
nem biztos, hogy mindenki számára meg- 
felelően. Ebben az esetben a DFS - mond- 
hatni tradicionálisan - segítségünkre lehet. 
Azoknak a felhasználóknak, akiknek nem 
megfelelő a jelenlegi adatszervezés, mutas- 
sunk egy olyan adatstruktúrát, ami nem va- 
lós ugyan, de mutatókat, pointereket tartal 
maz a valós adathelyekre. Ideális megoldás, 


hiszen az adatot nem kell elmozdítani a je- 
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lenlegi helyéről (sokaknak pont úgy jó, ahogy 
van), de láttathatjuk úgy, mint ha átcsoporto- 
sítottuk volna azokat. 

Hogyan is néz ki ez a gyakorlatban? 
Legyen A és B a két tényleges fájlszerver. 
Mindkettőnek számtalan megosztása van, 
köztük A:nak Dokumentumokl és B-nek Do- 
kumentumok2. Egy adott felhasználó kény- 


telen tudatosan csatlakozni mindkét szer- 


pointerek, jelen esetben az A szerver Doku- 
mentumokt és a B szerver Dokumentumok2 
megosztásaira mutatnak. 

Tetszőleges mennyiségű pointert helyez- 
hetünk el a DES root alatt, amelyek a valós 
célhelyekre mutatnak. Ennyi lenne a DFS? 
Nos, tulajdonképpen ennyi a Standalone 
DEFS-wváltozat, annyi kiegészítéssel, hogy a 
pointerek kialakításakor megadhatunk alter- 
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2. ábra. A Standalone DFS architektúrája 


verhez, sőt annak konkrét sharejeihez és az 
általa használt Dokumentumokat erről a két 
helyről megnyitni. Ha szeretnénk számára le- 


egyszerűsíteni az elérést, vegyük elő a Z szer- 


natívákat is a cél tekintetében, azaz ha a C 
szerver Dokumentumok1 megosztása ugyan- 
azzal az adattartalommal bír, mint az A szer- 


ver Dokumentumoklt-e, akkor a hibatűrés és 
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3. ábra. Az Active Directory integrált DES architektúrája 


vert, és jelöljük ki DES rootnak! A DES root 
egy olyan , megosztott könyvtár", amelynek 


alkönyvtárai nem (feltétlenül) valósak, csak 


MÁRCIUS-ÁPRILIS 


a terhelésmegosztás jegyében a DES root alat 
ti ,könyvtár" mindkét helyre egyaránt mu- 


tat. Ezt a DES a kliensgép számára listaként, 


ici 


zet 


mintegy folyamatosan változó sorrendiséggel 
közvetíti, tehát nagyszámú kliens esetén azok 
kb. egyenlő arányban oszlanak meg a tényle- 
ges célhelyek között. 

Itt jegyzendő meg, hogy a DFS root által 
felkínált , virtuális" könyvtárstruktúrára kat 
tintva nem a DFS-kiszolgáló keresi fel a valós 
célt, hogy leplezze a csalást! A kliensgép DFS- 
ügyfélkomponensének üzen, amelyik felke- 
resi a tényleges adathelyet. Ielepítettünk mi 
ilyet? Nem, de ez bizony szerényen megbújó 
része a Windowsnak ősidők óta. 

Igen ám, de mi a helyzet a módosított Do- 
kumentumokkal az azonos tartalmú célhelye- 
ken? Ha az A szerver Dokumentumokl-ében 
módosítunk, az eljut valahogy a C szerver Do- 
kumentumokl-ébe? Sajnos nem. Standalone 
DEFS esetén (hangsúlyozom, hogy nem a 
Windows szerver 2008-ban található DEFS- 
ről van szó!), a célhelyek csak olvasható Do- 
kumentumokkal legyenek tele, vagy változá- 
sok, módosítások esetén gondoskodjunk mi a 
konzisztenciáról. Jó, de hogyan? Akárhogyan 
- mondja a régi DES - ez már nem rám tarto- 
zik. Hát... köszi. Igazán kedves... 

Domain-Based, azaz Active Directory-in- 
tegrált DFS. Amikor megjelent a Windows 
2000 és az Active Directory, a DES sokat vál 
tozott - előnyére. Bár a Standalone-változat 
megmaradt, a Domain-Based sokat ígért, és 
azt be is váltotta. Rootreplikát alakíthattunk 
ki, azaz ha a DFS rootunk valamiért kiesett, 
fordulhattunk egy másikhoz, ahol ugyanaz a 
, virtuális" struktúra fogadott minket a valós 
célhelyekre mutató pointerekkel. Nagy előre- 
lépés! Főleg ha azt is számításba vettük, hogy 
nem is konkrétan a DFS-szerverre kellett hi- 
vatkozni, ha a rootot akartuk elérni. Az AD 
felkínált nekünk egy olyan belépési pontot, 
amely egy igen furcsa UNC path: Ndomain- 
névudfsrootnév. 

Az erre tett hivatkozáskor az AD szerepe 
nem ért véget, hiszen a kliens IP-címéből és a 
belépési pont mögötti rootreplikák IP-címeti- 
ből a DNS-sel karöltve könnyen irányíthatta 
a felhasználót egy olyan DFS roothoz, ami a 
klienssel azonos Site-on van. Azonos tartal 
mú DES rootok különböző telephelyeken? 
Bizony, de ha az adott telephelyen lévő root 
nem érhető el, akkor még mindig ott a távo- 
li - igaz, sokkal lassabban. Komoly változást 
hozott a Domain-Based DES a célhelyek alter- 
natíváinak kezelésében is: a File Replication 

Service, azaz FRS (NTEFRS) segítségével meg 
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lehetett tartani a különböző fizikai szerve- 
rek azonos adattartalmú területeinek kon- 


zisztenciáját. Hogy ez mennyire volt szoros, 





Role services: 





File Server 
B Distributed File System 
DFS Namespaces 
DFS Replication 
( ] File Server Resource Manager 
( ] Services for Network File System 
[ ] Windows Search Service 
s [] Windows Server 2003 File Services 
( ] File Replication Service 





( ] Indexing Service 





4. ábra. A DFS a Fájlkiszolgáló-szerepkör egy 
szolgáltatása 


az már az FRS-en múlt, mindenesetre tette a 
dolgát. Mit tett a DES, ha ezek az azonos tar 
talmú célhelyek különböző telephelyen vol 
tak? Akárcsak a root kiválasztásakor, itt is 
az AD-ban definiált Site-struktúra döntött: 
a klienst - lehetőség szerint - a vele azonos 
telephelyen lévő cél felé irányította. 

Hát ez már egész jó, nem? Kell ennél több? 
Dehogy! Elkezdtük használni, és... és elég so- 
kat bajlódtunk vele. No nem a DFS-sel magá- 
val, az rendben működött, hanem az a fránya 
FRS elég sok borsot tört az orrunk alá! Akár 
a rootreplikáknál, de főleg a célhelyek közti 
replikációnál misztikus hibák fordulhattak 
elő, amelyekre sok esetben a , net stop ntfrs 
- net start ntfrs" volt a megoldás. Gond volt 
a teljesítménnyel és a kommunikáció meg- 
bízhatóságával is, az FRS nem különösebben 
modern módszerekkel dolgozik. És az időzít 
hetőség? Ha nem szeretném, hogy hétköznap 
napközben az FRS foglalja a telephelyeket 
összekötő vonal amúgy is szűkös áteresztő- 
képességét? Vagy esetleg pont azt szeretném, 
hogy napközben biztosítsa a legszorosabb 
konzisztenciát? Igényként merült fel gyakran 
az is, hogy , de jó lenne DES nélkül jól össze- 
replikálni két szerveren adatterületeket, no 
és ha már úgyis itt van az FRS, nem lehetne 


esetleg vele?" 


DFS a Windows Server 2008-ban 


A fent említett problémákra és igényekre 
mind van megoldás, itt, a Windows Server 
2008-ban. Vegyük át a legfontosabb újítá- 
sokat szépen sorjában! A DES a Windows 


Server 2008 egy szerepköre (role), ami ennek 


ni 


megfelelően telepítendő, bár első ránézésre 
nem is látszik, hiszen a File kiszolgáló-sze- 
repkör része. Amit már a telepítés fázisá- 
ban észrevehetünk, az az, hogy a klasszikus 
DFS-funkcionalitás és a Replikáció külön- 
külön is kiválaszthatók. Számomra ez a klasz- 
szikus DFS-konfiguráció nélküli fájlrepliká- 
ció lehetőségét jelenti, bár ez a Windows 
Server 2003 R2-ben volt újdonság. A DES 
Managementben azután szemmel láthatóan 
külön kategóriát képviselnek a Névterek és 
a Replikáció. 

Névterek, namespaces. Lássuk, milyen 
lehetőségeink vannak, ha DEFS-t szeretnénk 
kialakítani! Az első lépés talán egy kis foga- 
lomiújraértelmezés, hiszen az új DFS-ben sok 


dolgot nem úgy hívnak, mint régen (lásd a 


táblázatot). 

Tegye tott Windows Server 2008 
DES Root — Namespace, azaz névtér 
DES Root Szerver — Namespace-szerver 

DFS Root Szerver replika — Namespace-szerver 

DFS Link — Folder Target 

DFS Link Replika — Folder Target 


I. táblázat. Minek mi a neve? 


Az első lépés a névtér létrehozása, amely- 
ben annak neve és legalább egy namespace- 
szerver megadása kötelező. Ezután követke- 
zik a DFS típusa, tehát előttünk a döntés- 
helyzet. 

Lehet hagyományos Standalone, amely 
nem sokban különbözik a ,ősi" DFS-válto- 
zattól, a varázsló a failover clusterrel való in- 
tegrálhatóságra felhívja ugyan a figyelmet, 
de ennek lehetősége - igaz, nem látszott a 
DEFS konzoljából, csak a Cluster adminiszt 
rációs felületéből - régebben is adott volt. 
Persze a Clusterre ebben az esetben szükség 
lehet, elsősorban akkor, ha a Root szerverün- 
ket - elnézést, a Standalone Namespace szer- 
verünket szeretnénk hibatűrővé tenni. 

A másik lehetőség a Domain-Based név- 
tér kialakítása, ami lehet , hagyományos" 
vagy Windows Server 2008 módú. Ez utóbbi 
egy jelentős újdonságot rejt, amelynek neve 
Access Based Enumeration. 

Mit is jelent ez? Segítségével elérhetjük, 
hogy felhasználóink a megosztáson belül csak 
azokat a könyvtárakat lássák, amelyeknek 


az eléréséhez valamilyen szintű jogosultsá- 


guk van. Végre! Egy rendszergazda nap mint 
nap kénytelen magyarázkodni azoknak a fel 
használóknak, akiknek nincs megfelelő jo- 
guk egy egyébként csábító nevű és feltehető- 
leg , roppant érdekes" tartalmú könyvtárhoz. 
Képzeljünk csak el egy, a publikus adatterüle- 
ten, kizárólag a HR-csoport számára fenntar- 
tott , lervezett Béremelések 2008-ban" nevű 
mappát! Hány sikertelen megnyitási kísérle- 
tet naplózhatnánk itt naponta? Ha ezt a map- 
pát mindenképpen a közös elérésű területen 
kell tartani, hát nyissunk parancssort a name- 
space-szerveren, és gépeljük be a ,,dfsutil 
property abde enable Wdomainnévmame- 
spacenév" utasítást, és a probléma egy csa- 
pásra megszűnik! Ott van ugyan a könyvtár, 
de a DES felől közelítő felhasználók nem lát 
ják. Amiről nem tudunk, az nem fáj... - tartja 
a bölcs mondás. Windows Server 2008 mó- 
dú Domain-Based DEFS-t akkor készíthetünk, 
ha a Namespacescszervereink Windows Server 
2008-at futtatnak, és az Active Directory do- 
mainünk funkcionalitási szintjét is átkapcsol 
tuk Windows Server 2008-ra. Ez természete- 
sen kizár minden régebbi operációs rendszert 
futtató tartományvezérlőt a domainből, a lé- 
pést éles környezetben jól gondoljuk meg! 
Ott tartottunk, hogy megvan a Namespace 
és legalább egy Namespacesszerver is, jöhet a 
folderek kialakítása a névtér alatt! Az új fold- 
er nevének megadásával a felhasználó által 
látható könyvtárnevet, míg a Folder Target 
definiálásával a célterületet határozzuk meg. 
Már most megadhatunk több Folder Targetet, 
amelyek a Domain-Based DES esetén repliká- 
ciós kapcsolatba kerülnek. Standalone DFS 
alatt a Folder Targetek hagyományosan nem 
replikálhatók? Dehogynem, most már bármi- 
kor beállíthatunk ebben az esetben is repli 
kációt, de ne vágjunk elébe a dolgoknak. Ha 
Domain-Based Namespace alatt készítjük a 
foldert és a hozzá tartozó Folder Targeteket, 
a DES itt is figyelembe veszi az AD és a DNS 
segítségével a kliens fizikai helyét, sőt ezt lehe- 
tőségünk van úgy finomítani, hogy a kliens 
számára esetleg nem is engedélyezzük a távoli 
site-on való célterület elérését. Új lehetőség 
továbbá a failback beállítása: ha a kliensünk 
a közeli Folder Target elérhetetlensége miatt 
egy távoli telephelyen lévő cél elérésére kény- 
szerült, biztosíthatjuk számára az automa- 
tikus visszatérést, amennyiben a helyi, azaz 
preferált Folder Target ismét munkába állt. 
Ne felejtsük el, hogy az ügyfélgép DFS-kliens 
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komponensét távirányítjuk, és ez cache-ben 
őrzi a tényleges célhelyeket. Lehetőségünk 
van a hivatkozások tárolási idejének módosí- 
tására is, amit akár a Namespace-en, akár az 
alá szervezett folder szintjén is megtehetünk. 

Hol is tartja a DFS a konfigurációt? 
Természetesen az Active Directory adatbá- 
zisban. A névtérszerver ebből időről időre 
másolatot készít, amit helyben, XML formá- 
tumban tárol. Alapértelmezés szerint a DFS 
metadata publikációja is a PDC Emulátor 
szerepbkörű DC-re hárul, ezen azonban mó- 
dosíthatunk, elérhetjük, hogy a DFS name- 
space-szerverünk ne az esetlegesen igen távoli 
PDC-t, hanem a legközelebbi DC-t faggassa a 
konfiguráció esetleges változásairól. Előbbit 
a konzisztenciára, utóbbit a skálázhatóságra 
optimalizált állapotnak hívjuk. 

Végül még egy apróság: a keresés lehetősé- 
ge. Akármennyire is magától értetődő a funk- 
ció, eddig nem volt. Most, íme, rendelkezésre 
áll. Abba azért belegondolhatunk, hogy a 
fájlrendszerbe irányuló kereséseink általában 
egy adott gép adataiban kutatnak. És a DES 
beépített keresése? Az bizony végrehajtja több 
gépen is, ahogy a folderek és a folder targetek 
megkívánják. Viszont az is igaz, hogy , csak" a 


keresett könyvtár megtalálására való. 


DFS-replikáció, DFS-R 
Külön bekezdést kapott a DFS-replikáció és 
talán nem érdemtelenül. Eddig a Windows 
2000-ben vagy a Windows Server 2003-ban 
egy legyintéssel elintézhettük volna: mi más 
intézhetné a replikációt, mint az FRS?! És 
most? Mi; is? Hát a DES! A Windows Server 
2003 R2-ben és a Windows Server 2008-ban 
a DES új szolgáltatással bővült, ez a DFS-rep- 
likáció. Mi lesz akkor az FRS-sel? Lassacskán 
felejtsük el, a DES környezetében minden- 
képp. Egy fontos dolga az FRS-nek azért meg- 
maradt, ez pedig az Active Directory Domain 
kontrollerek , SYSVOL" megosztásainak rep- 
likációja. Windows Server 2008-ban akár ezt 
a feladatot is átruházhatjuk a DFS-replikáció- 
ra, bár nem kötelező. 

Mitől jobb a DFES-replikáció, mint az FRS? 

[Ide egy olyan hosszú felsorolás kívánkozik, 
ami túlmutat az írás terjedelembeli lehetősé- 
gein, de a teljesség igénye nélküli: 
a A DFS-R a DES Management MMC kon- 

zolból konfigurálható. 
a Replikációs csoportokba szervezhetők a 


közreműködők és az adatterületek. 
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a A replikációs topológiák több séma és 
akár az egyéni elgondolások alapján is ki- 
alakíthatók. 

a Időzíthetőség és sávszélességre való opti- 
malizálhatóság jellemzi. 

z ,Staging folder" a változott állományok 
átmeneti tárolására, a ,last writer wins" 
szabály, amiből adódó konfliktusokra egy 
, ConflictAndDeleted" folder nyújtja a 
megoldást. 

a A változások replikációja akár bitszintű le- 
het, a replikációs forgalom automatikusan 
tömörített. 

a Nagymértékben leegyszerűsített a recov- 
ery-rmechanizmus, és van Standalone DFS- 
támogatás. 

A valós lista ennél sokkal hosszabb, de így 
is belátható, hogy nem véletlenül került bele 

a DFS-R már a Windows Server 2003 R2- 


Windows Server 2008 
RPC Async Pipes 
Asynchronous I/05 
Unbuffered [/Os 


Low Priority [/Os 
(terheléscsökkentés) 


Windows Server 2003 R2 
Multiple RPC calls 
Synchronous inputs/outputs 
Buffered I/Os 


Normal Priority [/05 


16 concurrent file 


4 concurrent file downloads 
downloads 


2. táblázat. A sebességnövekedésért felelős 
változtatások 


be is. Amiknek azonban igazán örülhetünk, 
azok a következő kérdésre adható válaszok: 

Mitől jobb a Windows Server 2008 DES- 
replikáció, mint a DFS-R a Windows Server 
2003 R2-ben? 

1. Tartalomfrissesség-vizsgálat (Content 
Freshness). Szükség lehet erre az új tulajdon- 
ságra akkor, ha a replikációban részt vevő 
szerverek egyike nagyon hosszú ideig van ,tá- 
vol", majd mikor ismét replikál, akkor már 
esetleg nem derül ki, hogy a rajta lévő ada- 
tok régen elavultak. Ha a Content Freshness 
nem lenne, a régi, elavult adatok a többi tag- 
ra visszaíródnának, illetve felülírhatnák az 
újabb változatokat. 

2. A váratlan leállások kezelése. Az NI FS 
fájlrendszerben bekövetkező változások az 
esetek többségében először memóriában, át 
meneti tárban helyezkednek el, és csak egy 
kis idő után íródnak le a fizikai lemezre. A 
DES-R replikáció adatbázisának szempontjá- 


ból viszont a változás már a diszkre írás előtt 


megtörténik. A köztes időben bekövetkező 
bármilyen katasztrófa - legyen az váratlan 
szerverleállás, vagy szabálytalan volume-dis- 
mount - a DFS-R adatbázis inkonzisztenciá- 
jához vezethet. Míg a Windows Server 2003 
R2 esetén ez a komplett DES-R adatbázis új- 
raépítésével és így rengeteg idővel járt, az új 
változat ezt az adatbázis újraépítése nélkül, 
azaz sokkal gyorsabban intézi el. 

3. Sokkal gyorsabb replikáció. A 
Windows Server 2008 DES-R elsősorban eb- 
ben jeleskedik. Mérhetően gyorsabban szink- 
ronizál mind kisebb, mind nagyobb fájlok 
esetén, köszönhető ez a tömörítés mellett a 
hatékonyabb sávszélesség-kihasználásnak. 

4. Reportképzés tesztállomány repliká- 
ciójával (Propagation Report). A Windows 
Server 2003 R2-ben is meglévő reportok 
mellé diagnosztikai célból bekerült report, 
ami nem a valós adatállományok, hanem egy 
tesztállomány replikációjával kapcsolatos ér 
tékeket mutatja meg. 

5. Az azonnali replikáció forszírozásának 
lehetősége (Replicate Now). Egy replikációs 
csoportban kijelölt célterületek közti repliká- 
ciót indítja el, függetlenül annak időzítésé- 
től. (SYSVOL replikációnál nem működik.) 

6. A Read Only Domain Controller 
(RODC) támogatása. Miután a DFS-repli 
kációba a tartományvezérlők SYSVOL-meg- 
osztása is belekeverhető, ebből az RODC 
sem maradhat ki. Itt viszont meg kell felelni 
az Active Directoryban definiált szabálynak, 
miszerint az RODC-ről nem származhat sem- 
miféle változás vissza a többi, írható-olvas- 
ható adatbázisú DC-re. Ez alól a SZTYSVOL 
sem kivétel. Amennyiben a SYSVOL rep- 
likációját az FRS helyett a DFS-R végzi, ezt 
annak is figyelembe kell vennie! Meg is teszi, 
viszont ez nem érinti az RODC esetleges, a 
SYSVOL tól különböző DFS-replikációs fel 
adatait. Ezekre az adatterületekre kimenő 
és bejövő replikációs kapcsolatokat egyaránt 
beállíthatunk. Egy pillanat! Mi is hangzott 
el már többször? A SYSVOL replikációjának 
lehetősége? Igen, ez az a téma, ami talán egy 
kicsit összetettebb annál, semmint hogy egy 
mondatban elintézzük. Nézzünk a körmére 


ennek az új lehetőségnek! 


A SYSVOL és a DFS-replikáció 
kapcsolata 

Mint ahogy már ebben a cikkben is többször 
szó volt róla, a tartományvezérlők SYSVOL 
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könyvtárainak egyezőségéről alapértelmezés 
szerint az FRS szolgáltatás gondoskodik, már 
a Windows 2000 óta. Nincs ez másként a 
Windows Server 2008-ban sem, viszont az 
FRS fölött sok szempontból eljárt az idő. 
Miért nem a DFS-R az alapértelmezés? Talán 
azért, mert a Windows Server 2008-as tarto- 
mányvezérlőkből kialakított domain egyéb 
rendelkezés híján nem zárja ki az esetleges 
régebbi (2000; 2003) Domain Controllereket 
sem. Ezek viszont eléggé meglepődnének, ha 
a SYSVOL ettől kezdve DFS-R módszerrel ér- 
kezne... Ha a SYSVOL replikációját a DFS-R- 
re szeretnénk bízni, első lépésként emeljük a 
tartomány funkcionalitási szintjét Windows 
Server 2008-ra! Igen ám, de ettől még mindig 
marad az FRS, ez csupán a lehetőséget terem- 
ti meg az átállásra. Akkor telepítsünk a tar- 
tományvezérlőkre DFS-replikációt! Megvan? 
Így már majdnem kész vagyunk, de még min- 
dig a régi módon replikálunk. 

Hogyan tovább? Az EFRS-ről DFS-R-re va- 
ló áttérés egy migrációs folyamat, amelyet 
kellő körültekintéssel - és ami a legfonto- 
sabb - fokozatosan végezzünk! Megjelent a 
Windows Server 2008-ban egy parancssori 
segédeszköz, a dísrmig.exe. A neve beszédes, 
két fő funkciója a migráció állapotának le- 
kérdezése és változtatása. Vigyázzunk vele, 
mert használata minden tekintetben globális 
eredménnyel jár: bármelyik DC-n kiadjuk a 
megfelelő jogosultsággal, az egész tartományt 
érintő változtatást jelent. Iehát, amennyiben 
a fenti feltételeknek megfeleltünk, elkezdhet 
jük a migrációt. Gépeljük be a parancssorba 
a , dísrmig /getglobalstate" utasítást, és lát 
hatjuk, hogy a migráció státusza , start". Ez 
még igazából semmit nem jelent, a SYSVOL- 
replikációt az FRS végzi. Milyen státuszok le- 
hetségesek (lásd a táblázatot)? 


0 START 

] PREPARED 
/ REDIRECIED 
3 ELIMINATED 


3. táblázat. Migrációs állapotok 


A cél természetesen az , Eliminated" állapot 
elérése, de csak ésszel, óvatosan. Következhet 
a , dísrmig /setglobalstate 1" utasítás, amely- 
nek hatására a migráció állapota mostantól 
, prepared". Most a DFS-R készít magának 
egy másolatot a SYSVOL mappáról, majd 
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egy másik DC DES-R szervizével megpróbál 
egy úgynevezett iniciális replikációt végrehaj- 
tani. Sikerült az összes tartományvezérlőn? 
Kérdezzük le a , dísrmig /getmigrationsta- 
te" paranccsal! Tegyük fel, hogy a visszajelk 
zés pozitív. Álljunk át a fent említett mód- 
szerrel a 2-es, azaz a , redirected" szintre! Mi 
is történik éppen? A tartományvezérlőkön 
futó DES-R szervizek magukhoz ragadták 
a SYSVOL replikációjának feladatát, de az 
FRS még ugyanúgy teszi a dolgát, ahogy ré- 





11/22/2007 3: 13... File Folder 








1 System32 2/13/2008 2:30 AM File Folder 
ki 2/6/2008 1O0L1AM File Folder 
2/13/2008 4:26 AM File Folder 

Ji tapi 11/22/2007 3:14... File Folder 
JÚ Tasks 11/22/2007 5:19... File Folder 
hi Temp 2/6/2008 4:16 AM — File Folder 





5. ábra. A régi és az új egymás mellett: migráció közben 


gen. Párhuzamosan működik mindkét rend- 
szer! Gyors állapotlekérdezés, megnyugodha- 
tunk, ha tényleg így van. Most következik a 
legfontosabb döntés: a harmadik szint, azaz 
az ,eliminated" forszírozása. 1-es vagy 2-es 
szintről bármikor vissza lehet lépni, bűnbá- 
nóan az FRS elé állni és megkérni, hogy foly- 
tassa mégis csak ő a STSVOL-eplikációt - 
, eliminated" szintről nincs visszatérés! Ha az 
állapotjelzés (, dísrmig /getmigrationstate") 
kedvező, belevághatunk. Forszírozzuk a 3-as 
szintet, és lekérdezzük az állapotot: 
minden OK! 

Mi is történt? A DES-R letöröl 
te az eredeti SYSVOL-t és annak 
SYSVOL DEFSR 


könyvtárral operál a továbbiakban. . 


ma af 








másolatával, a 














Eseménynapló, a DES log biztató 
hátradólhe- 





bejegyzésekkel tele, 








Event Viewer (Local) 

Custom Views 
Ez Windows Logs 

Applications and Services Li "89" 
f£] DFS Replication 
fe] Directory Service 
íz] DNS Server 
£-] File Replication Service 
íz] Hardware Events 
fe] Internet Explorer 
2] Key Management Servi 


Microsoft 


£] Windows PowersShell 
E Subscriptions 


adatbázist - persze üres, a STSVOL-epliká- 


ciós kényszerét nem tartalmazó változatot. 


A replikáció beállításai 

Ha a replikációs csoportokat megvizsgáljuk 
a DES Management konzolban, láthatjuk, 
hogy azok kialakítása roppant egyszerű - 
már ha nekünk kell egyáltalán kialakítani 
azokat. A Domain-Based DEFS replikációs fel 
adatai és a SYSVOL-eplikáció, amennyiben 
migráltunk rá, automatikusan bekerülnek 
a konzolba. Igény szerint ezeknek a paramé- 
tereit, azaz topológiáját és időzítését, sőt a 
szereplőket és a replikálandó adatterületeket 
is megváltoztathatjuk. Kikényszeríthetjük az 
azonnali replikációt is, az időzítéstől függet 
lenül. Nem igaz ez a SYSVOL replikációjá- 
ra, amit bár látunk a replikációs csoportok 
között, különösebben konfigurálni nem tu- 
dunk, de ez érthető. 

Van egy probléma, amin azért el kell gon- 
dolkodni: az egyirányú replikáció. Ha két 
adatterületet replikációs kapcsolatba hozunk, 
azok automatikusan oda-vissza továbbítják a 
változásokat. Az esetek többségében ez pont 
megfelelő, de vegyünk elő gondolatban egy 
, Main office-Branch office" scenariót! A 
Branch office, tegyük fel, csak olvasható vál 
tozatot kaphat egy, a Main office telephelyén 
elhelyezett könyvtárstruktúrából. Mit csinál 






File Replication Service 26 Events 
Date and Time LSource  ] EventiD Task... ] 
H 2/1 AM 


13555 None 





Ühe-ra 
Event 13552, NtFrs 





General ] Details I 





The File Replication Service is unable to add this computer to the following replica set: 
"DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" 


This could be caused by a number of problems such as: 
-- an invalid root path, 
-- a missing directory, 
-- a missing disk volume, 
-- a file system on the volume that does not support NTFS 5.0 








tünk. Viszont, ha már az esemény- 
naplóban járunk, pillantsunk csak 
rá az FRS naplójára! A helyzet ijesztő, leg- 
alábbis az FRS nagyon meg van ijedve: nem 
leli a replikálandó SZYSVOL mappát! Bár mi 
tudjuk, hogy ez nem igazán baj, de hogy le- 
hetne ezt az FRS-nek is elmondani? Két le- 
hetőség van, egyik sem túl elegáns: vagy leál 
lítjuk és , manual" indítási módba tesszük az 
ntfrs-szervizt, vagy (gondolva arra, hogy ta- 
lán valamikor valamiért még szükségünk lesz 
rá -nem tudnám ugyan megmondani, miért 
is lenne) a szerviz ideiglenes leállítása mellett 
kitöröljük a Jet adatbázisát a 2osystemroot9oN 
ntfrsyjet alól. Ebben az esetben az újraindu- 


ló NTERS létrehoz magának egy teljesen új 


6. ábra. A megijedt FRS-szolgáltatás kiabál 


junk? Fizikailag nagyon könnyen letiltható, 
de ez nem várt problémákat okozhat. Tegyük 
fel, hogy a Branch office-ban a helyi admi- 
nisztrátor letörli X könyvtárat. Másnap a 
Main office-ban módosítanak egy fájlt X-ben. 
Mi lesz? A Branch office szerverének DFS-R 
adatbázisa szétesik, ilyen esetekre nincs még 
felkészítve. Javaslat: a Branch office szerve- 
rén gondoskodjunk megosztási lehetőségről 
és NI FS-permissziókkal az írás és módosítás 
tiltásáról. A replikációt pedig hagyjuk inkább 
úgy, ahogy létrejön - kétirányúnak. 
Székács András 
(andras(oDedupro.hu) MCSE, MCTS, MCT, Számalk 
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Windows Server 2008 tanfolyamok 
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rendszergazdák és a szakmába frissen belépők 
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Teljes Windows Server 2008 6420 (2276 utódja) 
ze; Hálózati alapok 
tanfolyamkinalatunk 5 nap 


nattekinthető" formaban 


6421 (2277 utódja) 
Haladó hálózati ismeretek 
5 nap 


6424 6423 6430 
Active Directory alapok Windows Clustering Windows Server 2008 üzemeltetés 
3 nap 3 nap 5 nap 


6425 6427 6428 
Active Directory infrastruktúra kiépítése Internet Information Server Terminal Services 
3 2 nap 


6432 6426 6434 6437 


Active Directory monitorozása Active Directory mélyvíz PowerShell Windows 2008 
2 nap 3) nap  alkalmazásszerver 8 . 3 nap 


6431 
Hálózattervezés 
2 nap 





Tanfolyamok Windows Server 2003 MCSA/MCSE-k részére 
6415 - A Windows 2008 hálózati újdonságai és szolgáltatásai (3 nap) 

6416 - A Windows 2008 Active Directory újdonságai (3 nap) 

6417 - A Windows 2008 alkalmazáskiszolgáló újdonságai (3 nap) 
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